Hi Bin, On 27 November 2015 at 07:55, Bin Meng <bmeng...@gmail.com> wrote: > Hi Jagan, > > On Fri, Nov 27, 2015 at 2:54 AM, Jagan Teki <jt...@openedev.com> wrote: >> Hi Simon, >> >> Some how I'm unclear about your comments in previous series probably I >> my misunderstanding or something. let me explain about my plan on >> spi-nor development. >> >> The entire spi-flash code is generic for all means there is no >> separate code for any platform or device. So I call it as spi-flash >> core. spi-flash core having functionaries like read_jedec, flash >> read/write/erase all these were calling from cmd_sf using dm and >> non-dm version, here I'm replacing this MTD since it is core interface >> it doesn't handle any specific device or uclass and mtd operations are >> being used directly without any dm except the probe. >> >> So spi-flash shouldn't need dm and the respective probe sf_probe will >> follow dm as it allocates spi_flash and by taking spi_slave{} setup >> spi-uclass. spi-flash operation are common and there is no different >> ops for different drivers or devices or something and mtd_ops are >> manged directly from cmd_sf like nand and spi-nor in Linux. >> >> And once core sits stable spi-flash will implemented as spi-nor core >> and the bellowed drivers becomes spi-nor drivers like spi-nor to spi >> driver interface and spi-nor controller drivers these are dm-driven >> it's having dm ops similar to spi-flash ops and spi-flash no where >> required. > > My understanding is that when we introduce a new driver feature, it > should target driver model by default. This is to encourage boards to > take advantage of driver model, and all these *new* features. This is > what Simon asked for. As Simon mentioned, probably we should make the > SPI flash DM conversion complete now instead of adding any new feature > on top of it.
I'm not introduced any new driver feature here, instead I re-used the existing mtd core features and functionalities. The current code looks as below: -------------------------------------------- sf_probe.c: 1) having both non-dm and dm spi-flash and calls to 2) spi_flash_probe_slave for spi_flash detection and setting up hooks (spi_flash ops) sf_ops.c: 1) having all spi_flash ops definitions. These are the changes I did a) Moved spi_flash probing like definition of spi_flash_probe_slave from sf_probe.c to sf_ops.c so sf_ops.c having all core spi-flash code like flash detection, setting up hooks (spi_flash ops) and spi_flash ops definitions. b) from above point a) sf_probe.c having both dm and non-dm interface with a common call to sf_ops.c for spi-flash core functionalities using spi_flash_scan. c) Replaced existing spi_flash_mtd_register (sf_mtd.c) registration with generic mtd core using add_mtd_device in sf_probe.c for both dm and non-dm interfaces. d) In sf_ops.c Updated all mtd_info structure filling and replaced spi_flash ops hooks with mtd_info hooks - where dm_spi_flash_ops got dropped. e) Called mtd core operations from spi_flash.h like mtd_erase|write|read instead of direct calls to sf_ops.c with spi_flash operation as they are not needed, so mtd core calls will in turn call mtd hooks on spi-flash like nand, cfi and spi-nor in Linux. The code after these changes: ---------------------------------------- sf_probe.c: 1) having both non-dm and dm spi-flash and calls to 2) spi_flash_scan for spi-flash core functionalities and register with core mtd. sf_ops.c: 1) core spi-flash operations => spi_flash detection + setting up hooks (mtd ops) + having all mtd_info ops definitions. I couldn't understand what's wrong with this approach, because I have not added any new feature instead I reused it existing MTD core. I agree that the dm_spi_flash_ops are removed as mtd_info ops are used instead and sf_probe.c is still with dm. Please let me know your inputs. > >> >> cmd_sf >> ======= >> MTD >> ======= >> spi-nor or spi-flash >> =============== >> "spi-nor to spi drivers" and spi-nor controller driver >> ======================================= thanks! -- Jagan | openedev. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot