Re: [PATCH v3 0/8] Add the Quadspi driver for vf610-twr

[Huang Shijie <b32955@freescale.com>]

于 2013年09月05日 17:11, Gupta, Pekon 写道:
> No, SPI generic framework (struct spi_transfer, spi_message,...)
> should be kept independent of any MTD flash specific data handlers.
> <wangyuhang2014@gmail.com>  added two new fields (tx_nbits, rx_nbits)
> to spi_device because those properties are part of SPI protocol.
> But, 'dummy_cycles' is no related to SPI protocol. So it should be kept out
> of SPI generic framework.
> This is where if you could use DT based approach, things would have been
> simpler, because you give end-user the freedom to enter device-info from
> device datasheet.
ok. i think i do not need to change the spi code now.
>> >  
>> >  
>> >  
>> >  
>> >  
>> >  
>> >  
>>> >  >  Example: How to select opcodes in DT ?
>>> >  >  (step-1) eliminate opcode which cannot be used due to board constrains.
>>> >  >     your board connects only 2 data I/O between device and controller,  So you
>>> >  >     cannot use any of the QUAD  Read opcodes. Thus your choice is limited to
>>> >  >     DUAL or SINGLE modes only.
>> >  we have 4 data I/O lines between the device and controller, i only need
>> >  the Quad mode.:)
>> >  
> May be because you are currently working on a development EVM or
> demo board, so you can live with QUAD mode.
> But when customer will have custom boards with different QSPI devices
> then you would end-up  supporting all sorts of configurations:-)
> And in production scenarios, it’s the price economics which mostly dominates
> which part to choose and how to connect it on board.
> Like as I remember some freescale boards have WINBOND QSPI flash
> which uses different opcodes and semantics, so you might need to support
> that too in future.
>
> So my suggestion is think again. As you are inviting lot of re-work for yourself
> and for others too:-)
>
> Anyway, if you really want to continue with this is, then please re-name
> include/linux/mtd/spi-nor.h to
> include/linux/mtd/spi-fsl-quadspi.h
> because something specific for your driver should not conflict with
> generic spi-nor framework added later.
i think there is no specific thing for this driver. The S25FL128S is a 
common flash,
other person may uses it too. Could you show me what is specific?

so, i prefer to spi-nor.h.

thanks
Huang Shijie