Handling serial flashes on Broadcom SOCs

[Rafał Miłecki]

Broadcom SOCs have flash memories, some of them are serial flashes.
They are detected by ssb/bcma and need to be handled by some extra
drivers.

Access to that flash memories is specific to the Broadcom devices.
Reading is simple, as they are memory mapped. Writing is done with the
ChipCommon (bus device/core) registers.

The initial idea was to register platform device in ssb/bcma and then
access it in a separated driver placed in the mtd tree. However at
some point it was noticed (by Paul?) that (some of?) the chipsets
available at ssb/bcma buses are known from other devices. They are
usually available over SPI bus, and there are available drivers for
them. An example can be m25p80.c.

I can't say yet how much m25p80.c is compatible with chipsets on
Broadcom devices. Not all of them are available in m25p80.c, I'm
especially worried about Atmel flashes. There is only one Atmel entry
in m25p80.c and according to the SSB/BCMA code that devices require
different programming way.

I don't think extending m25p80.c to support SSB/BCMA is acceptable, so
we've two options now:

1) Just implement serial flashes support in separated driver operating
on ssb/bcma buses.
Easy to do, but requires some code duplication with m25p80.c

2) Fake SPI master in ssb & bcma and use m25p80.c
I think it's much more complicated, as there probably isn't any real
SPI on Broadcom devices. We have to fake/emulate it's operations. From
early overview, some words-tips are: struct spi_master,
spi_alloc_master, spi_register_master.
I also don't know well m25p80.c is going to support chipsets on
Broadcom devices. With some luck, we will have to extend it's database
only. But it may happen we will have to add some/many modifications in
m25p80.c as well.
Another problem is early flash access. To boot properly we need to
access serial flash very early to read NVRAM from it (plain text
partition with board settings). This may be required even before we
get "alloc" available, which may require additional extra hacks in
m25p80.c.

Personally I'm for the first option. It's much simpler, doesn't
require a lot of research (how to correctly emulate SPI calls?). I'm
also afraid that emulating SPI bus and adding extra hacks into
m25p80.c will require more code than simple duplication in a ssb/bcma
focused driver. I also can't predict how well serial flash will behave
in case of accessing it over emulated SPI. Is this going to be working
correct? Is this going to be slower/faster?

I wish we discuss this situation and take a one solid decision. I'm
afraid of second solution, but maybe someone of you sees additional
advantages and/or has some experience in that matter.

-- 
Rafał
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irc.bcm.serial.flash.log
Type: application/octet-stream
Size: 5115 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20130128/e9b3ef9b/attachment.obj>