Hi Thomas, On 6 November 2015 at 15:22, Jagan Teki <jt...@openedev.com> wrote: > Hi Thomas, > > On 6 November 2015 at 14:58, Thomas Chou <tho...@wytron.com.tw> wrote: >> Hi Jagan, >> >> On 2015年11月06日 16:07, Jagan Teki wrote: >>> >>> I appreciate your hardware expertise and am not questioning about that >>> as well. I do agree with the hw logic about altera qspi controller and >>> I don't have any questions with hw either. >>> >>> But my main intention here was about the software support since Linux >>> discussed about this subject and finally moved to spi-nor controllers >>> (though they don't use spi bus at-all) to spi-nor framework and Marek >>> knows this topic very well. >>> >>> I believe discussion about this topic much more clear if we send this >>> driver to Linux. >> >> >> Sorry that I was absent and didn't know about the topic discussed on Linux. >> The purpose of u-boot and Linux is quite different thought they may share >> some code. The drivers are different, too. Whatever they chose on Linux is >> not related here. > > I'm trying to interface the same standard wrt Linux stack, So adding > new features is reasonable and easy for developers to send the patches > if we have same stand-point as what Linux or vice-versa. Yes drivers > are bit different wrt Linux ie OK, anyway we need to implement with > dm-driven but the functionality flow will be same like > > Linux --> u-boot > mtd_utils --> cmd_sf > mtd_info -->mtd_info > spi-nor --> spi-nor > m25p80.c --> spi-nor-flash (dm-driven) > fsl-quadspi --> fsl-qspi (dm-driven) > > Finally, what is the main issue if we move to spi-nor instead of cfi? > agreed that it never used generic spi but even if it there in spi-nor > also it never used generic spi, spi-nor should also use mtd as cfi and > also it's serial flash it should be part of spi-nor that make more > sense to me. > >> >> Marek did agree that "The behavior of this device is closer to CFI flash.". >> This is what the core designed for, to replace the CFI flash. I am more >> concerned with users. Users can use memory commands to display and modify >> the content directly. This is very point where the driver should stand. > > Yes from uses point of view, it's a cfi flash but generally all cfi's > are parallel in nature so it's shouldn't treated as serial. If we use > sf user at least thought he would doing serial flash operations.
My intention is not to hold this, but once spi-nor is ready will you able to move it from here? thanks! -- Jagan | openedev. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
