From: Simon Horman <hidden> Date: 2016-01-04 10:36:59
Enable the QSPI controller in the alt device tree.
Based similar work for the silk board by by Vladimir Barinov and
Sergei Shtylyov.
Cc: Vladimir Barinov <redacted>
Cc: Sergei Shtylyov <redacted>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <redacted>
---
v2
* Added compatible = "fixed-partitions";
* Update partitioning scheme to reflect
ALT_MiniMonitor_Manual(SPI_Boot)_Rev0.01_e.pdf
* Tested on top of renesas-devel-20151228-v4.4-rc7
Read /dev/mtd0 with 512K blocks at 6.5Mb/s
---
arch/arm/boot/dts/r8a7794-alt.dts | 46 +++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
On Mon, Jan 4, 2016 at 11:36 AM, Simon Horman
[off-list ref] wrote:
Enable the QSPI controller in the alt device tree.
Based similar work for the silk board by by Vladimir Barinov and
Sergei Shtylyov.
Cc: Vladimir Barinov <redacted>
Cc: Sergei Shtylyov <redacted>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <redacted>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Jan 04, 2016 at 12:15:10PM +0100, Geert Uytterhoeven wrote:
On Mon, Jan 4, 2016 at 11:36 AM, Simon Horman
[off-list ref] wrote:
quoted
Enable the QSPI controller in the alt device tree.
Based similar work for the silk board by by Vladimir Barinov and
Sergei Shtylyov.
Cc: Vladimir Barinov <redacted>
Cc: Sergei Shtylyov <redacted>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <redacted>
Hi Simon,
On Mon, Jan 4, 2016 at 9:31 PM, Simon Horman [off-list ref] wrote:
On Mon, Jan 04, 2016 at 12:15:10PM +0100, Geert Uytterhoeven wrote:
quoted
On Mon, Jan 4, 2016 at 11:36 AM, Simon Horman
[off-list ref] wrote:
quoted
Enable the QSPI controller in the alt device tree.
Based similar work for the silk board by by Vladimir Barinov and
Sergei Shtylyov.
Cc: Vladimir Barinov <redacted>
Cc: Sergei Shtylyov <redacted>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Simon Horman <redacted>
Thanks, I have queued this up for v4.6.
Should we document "spansion,s25fl512s" for the benefit of checkpatch.pl?
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt used to point to
drivers/mtd/devices/m25p80.c for the list of supported chips.
That seems to have been changed lately. Now jedec,spi-nor.txt includes the
list, but lacks the manufacturers' names, so checkpatch.pl is still not happpy.
Brian: Shouldn't the manufacturers's names be added?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Jan 04, 2016 at 09:42:59PM +0100, Geert Uytterhoeven wrote:
On Mon, Jan 4, 2016 at 9:31 PM, Simon Horman [off-list ref] wrote:
quoted
Should we document "spansion,s25fl512s" for the benefit of checkpatch.pl?
Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt used to point to
drivers/mtd/devices/m25p80.c for the list of supported chips.
That seems to have been changed lately. Now jedec,spi-nor.txt includes the
list, but lacks the manufacturers' names, so checkpatch.pl is still not happpy.
Brian: Shouldn't the manufacturers's names be added?
We've had some of this discussion recently:
http://lkml.kernel.org/g/20151118194340.GF140057 at google.com
I don't think we can reasonably determine a good list of complete
strings, due to historical failures (IMO) in the SPI subsystem. We could
add a separate list of possible manufacturers, so people can do the MxN
pairing themselves.
checkpatch.pl has enough false positives that its author doesn't care to
fix that I'm not personally worried about yet another class of them. But
if you have good reasons and good patches for the documentation, I'm all
ears.
Regards,
Brian