From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bin Meng Date: Mon, 12 Oct 2015 11:07:02 +0800 Subject: [U-Boot] [PATCH v2] dm: implement a cfi flash uclass In-Reply-To: References: <1444289667-23775-1-git-send-email-thomas@wytron.com.tw> <1444548628-10119-1-git-send-email-thomas@wytron.com.tw> <561A23CE.6090900@wytron.com.tw> <561A54E2.9050803@wytron.com.tw> <561A643E.5000301@wytron.com.tw> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On Mon, Oct 12, 2015 at 5:47 AM, Simon Glass wrote: > Hi, > > On 11 October 2015 at 07:29, Thomas Chou wrote: >> Hi Bin, >> >> On 10/11/2015 08:43 PM, Bin Meng wrote: >>> >>> The spi-flash is converted to driver model, which is good, as there >>> are spi flashes from different vendors which have different op codes >>> thus need different drivers to handle. But for cfi-flash, almost every >>> cfi-flash we see in the market conforms to the same CFI spec, thus we >>> only need one driver (drivers/mtd/cfi_flash.c) to work with all these >>> flashes, right? Unless I am missing something recently, eg: some >>> vendors started to created flashes which are not 100% compatible with >>> the CFI spec? If this is the only single driver, I don't see the need >>> to create a special driver model uclass for it. Just an open >>> discussion. I am not saying we should, or we should not :) >> >> >> I had the same question myself. But I found that there are several uclasses >> which has only one driver. No worries. :) These single drivers under a uclass is probably due to we have not converted all other drivers to driver model yet. > > I don't see any problem with this in general, although the point with > CFI is that you are really implementing the uclass, as there will not > going to be any drivers (as I understand it). Yep, that's really my concern regarding to a new 'class' to be created but actually no additional driver will use that 'class'. > > Looking at SPI flash, it does have an API (read, write, erase). Could > CFI use the same API? That might mean that we could unify the two and > share a uclass. Yep, I believe this is a better approach. > > One approach may be to use a name like UCLASS_FLASH, and add some > operations to it. Then we can say that we have a real uclass. The > operations could come in a separate flash perhaps. > >> >>>> It is not just base address. There is device binding with compatible ids. >>>> There will be resources allocation, too. Please don't limit your >>>> imagination >>>> by my poor coding skill. >>> >>> >>> All there can be obtained from device tree. Being a non-DM driver does >>> not prevent you from using device tree. >> >> >> It is true. Yet using driver model does have some advantages over non-DM. It >> is more unified and dynamic. So I chose the DM way when I have to add device >> tree binding. You may find my patch quite trivial. Thanks to the DM >> framework. > > Regards, > Simon Regards, Bin