On Fri, Sep 13, 2013 at 12:12:14AM -0400, Huang Shijie wrote:
> On Thu, Sep 12, 2013 at 04:22:02PM +0100, David Woodhouse wrote:
> > But the controller driver shouldn't *have* that incestuous knowledge of
> > the command set of the chip that happens to be connected to it.
> I think the controller is designed for the NOR flash, yes, a little
> strange.
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).
> Mark and you want to create the LUT instruction sequence at the runtime,
> But there is some disadvantage if we do so:
> [1] low efficiency:
> [2] we may can not create all the LUT instruction sequence at the
> runtime. For example, the buffer program(OPCODE_PP):
>
> [3] We may can not create the LUT instruction sequence at the runtime,
> since we can not get enough information from the spi_transfer{}.
> A whole LUT instruction sequence may needs the following info:
What this is saying to me is that you should not be impementing this as
a SPI controller, trying to do that is breaking the abstracton that SPI
is offering. Like people have said SPI is just about byte streams.
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.
Attachment:
signature.asc
Description: Digital signature
