From owner-freebsd-embedded@FreeBSD.ORG Tue Mar 16 12:00:08 2010 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22BED106564A for ; Tue, 16 Mar 2010 12:00:08 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 48DE28FC08 for ; Tue, 16 Mar 2010 12:00:04 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id C6971C42DE; Tue, 16 Mar 2010 13:02:40 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id SoAJtQR31+2B; Tue, 16 Mar 2010 13:02:40 +0100 (CET) Received: from [10.0.0.75] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPA id 00EE5C42DD; Tue, 16 Mar 2010 13:02:39 +0100 (CET) Message-ID: <4B9F72BC.1050609@semihalf.com> Date: Tue, 16 Mar 2010 12:59:56 +0100 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: Andrew Turner , Luiz Otavio O Souza References: <0AE04EFA-A3EB-4939-BD81-607C00355B67@semihalf.com> <20100314165825.121d346b@fubar.geek.nz> <4B9E1697.9090602@semihalf.com> <20100316101044.0401295e@fubar.geek.nz> In-Reply-To: <20100316101044.0401295e@fubar.geek.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: NAND Flash Framework for review X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 12:00:08 -0000 Andrew Turner wrote: > On Mon, 15 Mar 2010 12:14:31 +0100 > Grzegorz Bernacki wrote: >>>> Chip drivers: >>>> - lnand and snand have magic numbers to figure out which drive to >>>> use. We should move these to a flag in the chip parameters. >>> We just need to add the chip size in nand_params and based on that >>> we can calculate the number of address cycles (see below) and the >>> type of chip (if chip >= 128MB and pagesize > 512 then you have a >>> large page device). >>> >> Yes, I was thinking about adding size of page and column address to >> parameters of nfc_send_address. > Why not just send each address byte separately like when the command is > sent? This will then push the requirement to know how many address > bytes to the chip driver. > I choose to send whole address in one call to make implementation of mpc8572 driver easier. This controller requires to divide address into block number and page & column number and write them into corresponding registers. It would be complicated (however, not impossible) to combine full address from bytes sending via consecutive nfc_send_address calls. On the other hand sending whole address in one call should not complicated drivers for controllers which just send address byte after byte. I was thinking about adding address type parameter to nfc_send_address(). It will tell controller how many address cycles chip requires. It will be defined using pattern (row_bytes << 4) | (col_bytes), for example: #define ADDR_TYPE_2ROW_1COL 0x21 #define ADDR_TYPE_2ROW_2COL 0x22 #define ADDR_TYPE_2ROW 0x20 (for erase command) #define ADDR_TYPE_ID 0xff (for read id command) It will allow to get rid of (-1) value for unused parameters. Also maybe it would be better to define address as a structure struct nand_addr { uint32_t row; uint32_t column; uint8_t id; uint8_t type; } The second thing is wait for ready/busy pin. I will add it to nfc methods. When not implemented it will return ENXIO by default. It will be used in nandbus_wait_ready function. It will be called in loop instead of sending STATUS command (unless it return ENXIO on first invocation). Is it good approach? What do you think? thanks, grzesiek