[U-Boot] [PATCH v2 2/2] mtd: add altera quadspi driver

[Jagan Teki]

Hi Thomas,

On 6 November 2015 at 15:22, Jagan Teki <jteki at openedev.com> wrote:
> Hi Thomas,
>
> On 6 November 2015 at 14:58, Thomas Chou <thomas at 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.