From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 4.mo2.mail-out.ovh.net ([87.98.172.75] helo=mo2.mail-out.ovh.net) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1W0yNC-0006mX-6Q for linux-mtd@lists.infradead.org; Wed, 08 Jan 2014 19:01:04 +0000 Received: from mail617.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo2.mail-out.ovh.net (Postfix) with SMTP id 7EDB7FFA69C for ; Wed, 8 Jan 2014 20:00:38 +0100 (CET) Message-ID: <52CDA032.3010804@overkiz.com> Date: Wed, 08 Jan 2014 20:00:02 +0100 From: boris brezillon MIME-Version: 1.0 To: Jason Gunthorpe Subject: Re: [RFC PATCH 3/9] of: mtd: add NAND timings retrieval support References: <1389190924-26226-1-git-send-email-b.brezillon@overkiz.com> <1389190924-26226-4-git-send-email-b.brezillon@overkiz.com> <20140108183418.GA12358@obsidianresearch.com> In-Reply-To: <20140108183418.GA12358@obsidianresearch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: devicetree@vger.kernel.org, Russell King , linux-doc@vger.kernel.org, dev@linux-sunxi.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Rob Landley , Grant Likely , Maxime Ripard , David Woodhouse , linux-arm-kernel@lists.infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hello Jason, Le 08/01/2014 19:34, Jason Gunthorpe a écrit : > On Wed, Jan 08, 2014 at 03:21:58PM +0100, Boris BREZILLON wrote: > >> +int of_get_nand_timings(struct device_node *np, struct nand_timings *timings) >> +{ >> + memset(timings, 0, sizeof(*timings)); >> + of_property_read_u32(np, "tCLS-min", &timings->tCLS_min); >> + of_property_read_u32(np, "tCLH-min", &timings->tCLH_min); >> + of_property_read_u32(np, "tCS-min", &timings->tCS_min); > [..] > > A while ago when discussing another controller it was pointed out > these values are all auto-probable directly from the NAND via a ONFI > defined GET FEATURE @0x01 query, and adding these timings to the DT > was NAK'd.. > > Basically you set the interface to the slowest ONFI timing mode, do > the GET FEATURE to the NAND chip and then increase the interface speed > to the highest mutually supported ONFI mode. > Is there some reason you need to encode this in the DT? What if the NAND does not support the ONFI interface (and this is exactly the case for the NAND available on the cubietruck board: H27UCG8T2ATR). But I'm glag to hear about this ONFI feature :). I'll add a function to retrieve these timings if the NAND support the ONFI interface. Best Regards, Boris > > Jason From mboxrd@z Thu Jan 1 00:00:00 1970 From: b.brezillon@overkiz.com (boris brezillon) Date: Wed, 08 Jan 2014 20:00:02 +0100 Subject: [RFC PATCH 3/9] of: mtd: add NAND timings retrieval support In-Reply-To: <20140108183418.GA12358@obsidianresearch.com> References: <1389190924-26226-1-git-send-email-b.brezillon@overkiz.com> <1389190924-26226-4-git-send-email-b.brezillon@overkiz.com> <20140108183418.GA12358@obsidianresearch.com> Message-ID: <52CDA032.3010804@overkiz.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello Jason, Le 08/01/2014 19:34, Jason Gunthorpe a ?crit : > On Wed, Jan 08, 2014 at 03:21:58PM +0100, Boris BREZILLON wrote: > >> +int of_get_nand_timings(struct device_node *np, struct nand_timings *timings) >> +{ >> + memset(timings, 0, sizeof(*timings)); >> + of_property_read_u32(np, "tCLS-min", &timings->tCLS_min); >> + of_property_read_u32(np, "tCLH-min", &timings->tCLH_min); >> + of_property_read_u32(np, "tCS-min", &timings->tCS_min); > [..] > > A while ago when discussing another controller it was pointed out > these values are all auto-probable directly from the NAND via a ONFI > defined GET FEATURE @0x01 query, and adding these timings to the DT > was NAK'd.. > > Basically you set the interface to the slowest ONFI timing mode, do > the GET FEATURE to the NAND chip and then increase the interface speed > to the highest mutually supported ONFI mode. > Is there some reason you need to encode this in the DT? What if the NAND does not support the ONFI interface (and this is exactly the case for the NAND available on the cubietruck board: H27UCG8T2ATR). But I'm glag to hear about this ONFI feature :). I'll add a function to retrieve these timings if the NAND support the ONFI interface. Best Regards, Boris > > Jason From mboxrd@z Thu Jan 1 00:00:00 1970 From: boris brezillon Subject: Re: [RFC PATCH 3/9] of: mtd: add NAND timings retrieval support Date: Wed, 08 Jan 2014 20:00:02 +0100 Message-ID: <52CDA032.3010804@overkiz.com> References: <1389190924-26226-1-git-send-email-b.brezillon@overkiz.com> <1389190924-26226-4-git-send-email-b.brezillon@overkiz.com> <20140108183418.GA12358@obsidianresearch.com> Reply-To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20140108183418.GA12358-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> List-Post: , List-Help: , List-Archive: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-Subscribe: , List-Unsubscribe: , To: Jason Gunthorpe Cc: Maxime Ripard , Rob Landley , Russell King , David Woodhouse , Grant Likely , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dev-3kdeTeqwOZ9EV1b7eY7vFQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org Hello Jason, Le 08/01/2014 19:34, Jason Gunthorpe a =E9crit : > On Wed, Jan 08, 2014 at 03:21:58PM +0100, Boris BREZILLON wrote: > >> +int of_get_nand_timings(struct device_node *np, struct nand_timings *ti= mings) >> +{ >> + memset(timings, 0, sizeof(*timings)); >> + of_property_read_u32(np, "tCLS-min", &timings->tCLS_min); >> + of_property_read_u32(np, "tCLH-min", &timings->tCLH_min); >> + of_property_read_u32(np, "tCS-min", &timings->tCS_min); > [..] > > A while ago when discussing another controller it was pointed out > these values are all auto-probable directly from the NAND via a ONFI > defined GET FEATURE @0x01 query, and adding these timings to the DT > was NAK'd.. > > Basically you set the interface to the slowest ONFI timing mode, do > the GET FEATURE to the NAND chip and then increase the interface speed > to the highest mutually supported ONFI mode. > Is there some reason you need to encode this in the DT? What if the NAND does not support the ONFI interface (and this is exactly the case for the NAND available on the cubietruck board: H27UCG8T2ATR). But I'm glag to hear about this ONFI feature :). I'll add a function to retrieve these timings if the NAND support the ONFI interface. Best Regards, Boris > > Jason --=20 You received this message because you are subscribed to the Google Groups "= linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/groups/opt_out. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757348AbaAHTAn (ORCPT ); Wed, 8 Jan 2014 14:00:43 -0500 Received: from 4.mo2.mail-out.ovh.net ([87.98.172.75]:52697 "EHLO mo2.mail-out.ovh.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751273AbaAHTAi (ORCPT ); Wed, 8 Jan 2014 14:00:38 -0500 Message-ID: <52CDA032.3010804@overkiz.com> Date: Wed, 08 Jan 2014 20:00:02 +0100 From: boris brezillon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jason Gunthorpe CC: Maxime Ripard , Rob Landley , Russell King , David Woodhouse , Grant Likely , devicetree@vger.kernel.org, linux-doc@vger.kernel.org, dev@linux-sunxi.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 3/9] of: mtd: add NAND timings retrieval support References: <1389190924-26226-1-git-send-email-b.brezillon@overkiz.com> <1389190924-26226-4-git-send-email-b.brezillon@overkiz.com> <20140108183418.GA12358@obsidianresearch.com> In-Reply-To: <20140108183418.GA12358@obsidianresearch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 11549762721196701930 X-Ovh-Remote: 78.236.240.82 (cha74-5-78-236-240-82.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejtddrfedtucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejtddrfedtucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Jason, Le 08/01/2014 19:34, Jason Gunthorpe a écrit : > On Wed, Jan 08, 2014 at 03:21:58PM +0100, Boris BREZILLON wrote: > >> +int of_get_nand_timings(struct device_node *np, struct nand_timings *timings) >> +{ >> + memset(timings, 0, sizeof(*timings)); >> + of_property_read_u32(np, "tCLS-min", &timings->tCLS_min); >> + of_property_read_u32(np, "tCLH-min", &timings->tCLH_min); >> + of_property_read_u32(np, "tCS-min", &timings->tCS_min); > [..] > > A while ago when discussing another controller it was pointed out > these values are all auto-probable directly from the NAND via a ONFI > defined GET FEATURE @0x01 query, and adding these timings to the DT > was NAK'd.. > > Basically you set the interface to the slowest ONFI timing mode, do > the GET FEATURE to the NAND chip and then increase the interface speed > to the highest mutually supported ONFI mode. > Is there some reason you need to encode this in the DT? What if the NAND does not support the ONFI interface (and this is exactly the case for the NAND available on the cubietruck board: H27UCG8T2ATR). But I'm glag to hear about this ONFI feature :). I'll add a function to retrieve these timings if the NAND support the ONFI interface. Best Regards, Boris > > Jason