On Fri, Sep 13, 2013 at 12:55:47PM +0800, Huang Shijie wrote: > 于 2013年09月13日 04:56, Mark Brown 写道: > > I think this is part of the problem - you're trying to represent > > something that isn't really a SPI controller as a SPI controller (or at > > least trying to implement functionality beyond that which a SPI > > controller has). > The QuadSpi is not a traditional SPI controller, but i think it is still > a SPI controller. > It connects and controls the SPI NOR FLASH, so what do you think it is? I think it is a SPI flash controller because... > But the Quadspi controller can not work with the byte streams directly, > it works with the LUT instruction sequences, so we have to parse the > byte streams, > and then uses the right LUT to trigger the transaction. ...it has a programming model that seems strongly oriented around that. The device can offer a SPI interface too but as you say that's going to be less efficient. Externally it is still SPI but in terms of what it is offering to the processor the functionality you are trying to support looks like it will work a lot better if the code using it understands that it is talking to a flash rather than having a SPI driver which tries to reverse engineer the data that's being sent to it. > > I think what you should be doing is refactoring the MTD code which > > interfaces to SPI flashes to split out the code so that there's an > > abstraction which can express what this controller (and presumably > > other controllers) can do and then implement this functionaltiy at > > that level. > If i follow this advice, i have to create a new file cloned by the m25p80.c, > and replace all the SPI APIs with other APIs. Not quite, you need to split that file up so that there is an API between the flash chip code and the SPI code - the code for the flash chip should be shared between regular SPI and other controllers like this one. > I have no idea what APIs can be used to replace the SPI APIs. You will need to create them.
Attachment:
signature.asc
Description: Digital signature
