[PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR
Huang Shijie
b32955 at freescale.com
Thu Dec 5 22:07:14 EST 2013
On Thu, Dec 05, 2013 at 01:20:48AM -0800, Brian Norris wrote:
> SPI is not used only for SPI NOR; it is useful for other things, like
> communicating with off-chip peripherals or microcontrollers, supporting
> touchscreens, LEDs, media controllers, etc. So with a SPI NOR framework
> living only in the MTD subsystem, I have to write two drivers: one
> (under drivers/spi/) to use only-(a) for controlling non-flash SPI
> devices, and one (under drivers/mtd/) to manage (a)+(b) on SPI NOR
> flash.
If the NOR is connected to a SPI bus controller which can attaches other SPI
devices too, I think you use a pure SPI driver to access it;
If the NOR is connected to a SPI-NOR controller such as your spi-nor controller
, you can use a SPI-NOR driver to access it.
Does your NOR flash connect to both the SPI bus controller and SPI-NOR
controller at the same time? :) If it does connect to both of the controllers,
I do not know how to handle it too.
>
> If, however, we can define a spi_nor_transfer like Angus suggested, and
> if we take that a step further and make it a first-class (but optional)
> citizen of the SPI framework, then we could have drivers that support
> SPI-only, SPI-NOR-only, or both.
>
I guess Mark will not agree with this. :)
thanks
Huang Shijie
> Now, I'm not sure how exactly that sort of proposal would work yet, but
> I wanted to test the waters to see
> - if this is a complete distortion of what Angus or David may have
> suggested;
> - if Mark thinks this is reasonable, or if he thinks I'm spouting
> nonsense; and
> - if there is some obvious alternate way to support what I describe
> without moving the SPI-NOR layer into the SPI subsystem.
>
> Brian
>
More information about the linux-arm-kernel
mailing list