From patchwork Sat Feb 11 12:59:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Ladislav Michl X-Patchwork-Id: 9567965 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6379260572 for ; Sat, 11 Feb 2017 12:59:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 45ADF23B24 for ; Sat, 11 Feb 2017 12:59:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 271A428534; Sat, 11 Feb 2017 12:59:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DEBFB23B24 for ; Sat, 11 Feb 2017 12:59:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753379AbdBKM7U (ORCPT ); Sat, 11 Feb 2017 07:59:20 -0500 Received: from eddie.linux-mips.org ([148.251.95.138]:52408 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753198AbdBKM7T (ORCPT ); Sat, 11 Feb 2017 07:59:19 -0500 Received: (from localhost user: 'ladis' uid#1021 fake: STDIN (ladis@eddie.linux-mips.org)) by eddie.linux-mips.org id S23992136AbdBKM7RJmZWp (ORCPT ); Sat, 11 Feb 2017 13:59:17 +0100 Date: Sat, 11 Feb 2017 13:59:16 +0100 From: Ladislav Michl To: Roger Quadros Cc: Tony Lindgren , linux-omap@vger.kernel.org, Javier Martinez Canillas , Enrico Butera , Eduard Gavin , Enric Balletbo i Serra , =?iso-8859-2?Q?Agust=ED?= Fontquerni Subject: Re: Support either NAND or OneNAND on omap3-gpmc CS0 Message-ID: <20170211125916.inojzppkuvsees2r@lenoch> References: <20160814084313.GA699@localhost.localdomain> <9706512a-a5ad-17c7-0867-4f592529fc8a@ti.com> <20160816185043.GA12255@localhost.localdomain> <20160817144922.3jwrwj67qjdsa2n7@atomide.com> <31d58234-8f57-b988-689a-bbcf6f56cb68@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <31d58234-8f57-b988-689a-bbcf6f56cb68@ti.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi all, finally found some time to dig into this deeper. It works now and patches used will be sent as followups to this mail. I was unable to find datasheet for OneNAND chip used on IGEPv2 boards, so I copied timings from N900. It works, but it would be nice to have something more reasonable. Agustí? On Thu, Aug 18, 2016 at 12:06:01PM +0300, Roger Quadros wrote: > On 17/08/16 17:49, Tony Lindgren wrote: > > * Ladislav Michl [160816 11:51]: > >> Hi Roger, > >> > >> On Mon, Aug 15, 2016 at 10:22:45AM +0300, Roger Quadros wrote: > >>> Hi Ladis, > >>> > >>> On 14/08/16 11:43, Ladislav Michl wrote: > >>>> Hi there, > >>>> > >>>> some IGEPv2 boards comes either with NAND or OneNAND flash memory and I'd > >>>> like to support that with single kernel and fdt blob. As U-Boot can > >>>> already detect flash type used I thought that having both onenand@0,0 > >>>> and nand@0,0 nodes in FDT would be easiest method. Bootloader could then > >>>> set status="disabled" property on memory not detected. > >>> > >>> Yes, that should work. And indeed does. Following patch against U-Boot's git was used: Subject: [PATCH] igep00x0: fixup FDT according to detected flash type Signed-off-by: Ladislav Michl --- board/isee/igep00x0/igep00x0.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) > >> That logic should be positive or negative? There are both aproaches > >> present in kernel and it is not immediately obvious under what cimcumstaces > >> is one better than another. Having both enabled by default means higher > >> probability that kernel boots even if bootloader does not support > >> FDT manipulation, but I'm unsure wheneven probe code is robust enough > >> not to break anything. Thoughts? > > > > We "should" be able to have both enabled in the dts just fine have > > it probed and have onenand or nand probe bail out for the one not found. > > Not sure what happens with that right now though :) > > That should work as well. As both request for CS0 space, the 2nd one will > fail to be probed. Once DT child is found its chip select is claimed and not returned back even if device is not found. We had to change this if we want to be able to leave both enabled. Is it worth doing so? Patchset that follows is a first draft as we only support OF enabled kernels, something should be done with all that nand and onenand stuff in arch/arm/mach-omap2 anyway :-) Comments are welcome and very appreciated in advance. Thank you, ladis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c index 65cc7dfdec..e032f313a6 100644 --- a/board/isee/igep00x0/igep00x0.c +++ b/board/isee/igep00x0/igep00x0.c @@ -214,6 +214,20 @@ void board_mmc_power_init(void) #endif #ifdef CONFIG_OF_BOARD_SETUP +static int ft_enable_by_compatible(void *blob, char *compat, int enable) +{ + int off = fdt_node_offset_by_compatible(blob, -1, compat); + if (off < 0) + return off; + + if (enable) + fdt_status_okay(blob, off); + else + fdt_status_disabled(blob, off); + + return 0; +} + int ft_board_setup(void *blob, bd_t *bd) { #ifdef CONFIG_FDT_FIXUP_PARTITIONS @@ -224,6 +238,11 @@ int ft_board_setup(void *blob, bd_t *bd) fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes)); #endif + ft_enable_by_compatible(blob, "ti,omap2-nand", + gpmc_cs0_flash == MTD_DEV_TYPE_NAND); + ft_enable_by_compatible(blob, "ti,omap2-onenand", + gpmc_cs0_flash == MTD_DEV_TYPE_ONENAND); + return 0; } #endif