linux-mips
[Top] [All Lists]

RE: [PATCH V5 16/17] SPI: MIPS: lantiq: add FALCON spi driver

To: John Crispin <blogic@openwrt.org>, Grant Likely <grant.likely@secretlab.ca>
Subject: RE: [PATCH V5 16/17] SPI: MIPS: lantiq: add FALCON spi driver
From: "Langer Thomas (LQDE CPE AE SW)" <thomas.langer@lantiq.com>
Date: Tue, 29 May 2012 13:05:18 +0000
Accept-language: de-DE, en-US
Cc: Ralf Baechle <ralf@linux-mips.org>, "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>, "spi-devel-general@lists.sourceforge.net" <spi-devel-general@lists.sourceforge.net>
In-reply-to: <4FC0DEEC.8050204@openwrt.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
References: <1337521579-1597-1-git-send-email-blogic@openwrt.org> <20120525233845.BD93C3E0BD2@localhost> <4FC0DEEC.8050204@openwrt.org>
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AQHNNo77Z0i1R71JSEmL/txXede8opbbEGeAgADtHACABHeJQA==
Thread-topic: [PATCH V5 16/17] SPI: MIPS: lantiq: add FALCON spi driver
Hello Grant, hello John,

John Crispin wrote on 2012-05-26:
> 
>> What exactly does this mean?  How does it not support any other type
>> of SPI peripheral?  SPI is a really simple protocol, so what is it
>> about this hardware that prevents it being used with other SPI
>> hardware?
>> 
>> I see a big state machine that appears to interpret the messages and
>> pretend to be an SPI slave instead of telling linux about the real
>> device.  /me wonders if it should this instead be a block device
>> driver?
>> 
> Thomas will need to comment on this part
> 
The hardware is an "EBU" (External Bus Unit) for different type of memories 
and flashes (NOR, NAND and serial).
One of the features of this EBU is the "execute in place" for serial flashes.
This shows that there is some logic in the hardware for automatic reading,
all other actions must be done using a specific cmd register.

Even if there are some restrictions from the hardware state machine,
the goal was to use the standard driver for serial flash devices (m25p80).
Otherwise, with a dedicated block device driver, we would have to duplicate
much of this code and had to maintain an own list of supported flash chips.

I hope this reason is good enough for getting this driver accepted.

Best Regards,
Thomas


<Prev in Thread] Current Thread [Next in Thread>