21 May, 2014
1 commit
-
Make of_device_id array const, because all OF functions
handle it as const.Signed-off-by: Jingoo Han
Signed-off-by: Brian Norris
17 Apr, 2014
1 commit
-
Compile-testing for a 64-bit arch uncovers several bad casts:
In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from drivers/mtd/devices/st_spi_fsm.c:15:
drivers/mtd/devices/st_spi_fsm.c: In function ‘stfsm_read_fifo’:
drivers/mtd/devices/st_spi_fsm.c:758:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
BUG_ON((((uint32_t)buf) & 0x3) || (size & 0x3));
...Use uintptr_t instead of uint32_t, since it's guaranteed to be
pointer-sized.We also see this warning, if size_t is not 32 bits wide:
In file included from drivers/mtd/devices/st_spi_fsm.c:15:0:
drivers/mtd/devices/st_spi_fsm.c: In function ‘stfsm_mtd_write’:
include/linux/kernel.h:712:17: warning: comparison of distinct pointer types lacks a cast [enabled by default]
(void) (&_min1 == &_min2); \
^
drivers/mtd/devices/st_spi_fsm.c:1704:11: note: in expansion of macro ‘min’
bytes = min(FLASH_PAGESIZE - page_offs, len);
^Just use min_t() to force the type conversion, since we don't really
want to upgrade 'page_offs' and 'bytes' to size_t; they only should be
handling
Acked-by: Lee Jones
15 Apr, 2014
9 commits
-
Many of the serial_flash_cmds.h opcodes are duplicated with spi-nor.h.
Let's begin to unify them.Signed-off-by: Brian Norris
Acked-by: Lee Jones
Reviewed-by: Marek Vasut -
Begin to unify the differences between serial_flash_cmds.h and
spi-nor.h.Signed-off-by: Brian Norris
Acked-by: Lee Jones
Reviewed-by: Marek Vasut -
These are also in serial_flash_cmds.h. (FWIW, I didn't know the C
preprocessor allowed redefinitions without warning like this.)Signed-off-by: Brian Norris
Acked-by: Lee Jones
Reviewed-by: Marek Vasut -
This patch adds support for the Macronix MX25L3255E device. Unlike the other
Macronix devices we have seen, this device supports WRITE_1_4_4 at reasonable
frequencies. Rather than masking out WRITE_1_4_4 support altogether, we now
rely on the table parameters to indicate whether or not WRITE_1_4_4 should be
used.Signed-off-by: Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Add Spansion S25FL032P to the list of known devices.
Signed-off-by: Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
This patch refactors the fsm_read_status() and fsm_write_status() code to
support 1 or 2 byte operations, with a specified command. This allows us to
remove device/register specific code, such as the N25Q fsm_wrvcr() function.The 'QE' configuration code is updated accordingly, with minor tweaks to ensure
the register values are only written if actually required. One notable change
in this area is that the 'W25Q_STATUS_QE' bit-field is now defined with respect
to the 'SR2' register, rather than the combined 'SR1+SR2' register which is only
used for write operations.Signed-off-by: Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Update the configuration of the Macronix 'QE' bit, such that
we only set or clear the bit if required.Signed-off-by: Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Support for the Macronix 32-bit addressing scheme was originally developed using
the MX25L25635E device. As is often the case, it was found that the presence of
a "WAIT" instruction was required for the "EN4B/EX4B" FSM Sequence to complete.
(It is known that the SPI FSM Controller makes certain undocumented assumptions
regarding what constitutes a valid sequence.) However, further testing
suggested that a small delay was required after issuing the "EX4B" command;
without this delay, data corruptions were observed, consistent with the device
not being ready to retrieve data. Although the issue was not fully understood,
the workaround of adding a small delay was implemented, while awaiting
clarification from Macronix.The same behaviour has now been found with a second Macronix device, the
MX25L25655E. However, with this device, it seems that the delay is also
required after the 'EN4B' commands. This discovery has prompted us to revisit
the issue.Although still not conclusive, further tests have suggested that the issue is
down to the SPI FSM Controller, rather than the Macronix devices. Furthermore,
an alternative workaround has emerged which is to set the WAIT time to
0x00000001, rather then 0x00000000. (Note, the WAIT instruction is used purely
for the purpose of achieving "sequence validity", rather than actually
implementing a delay!)The issue is now being investigated by the Design and Validation teams. In the
meantime, we implement the alternative workaround, which reduces the effective
delay from 1us to 1ns.Signed-off-by: Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Add Macronix MX25L25655E to the list of known devices.
Signed-off-by: Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris
20 Mar, 2014
29 commits
-
Reported-by: Brian Norris
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Reported-by: Brian Norris
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Reported-by: Brian Norris
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Reported-by: Brian Norris
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Reported-by: Brian Norris
Signed-off-by: Lee Jones
[Brian: tweaked a bit]
Signed-off-by: Brian Norris -
The old API expected a "partitions" property provided a phandle to a
separate partitions node, which itself contained yet more nodes each
representing one partition. The new API rids the requirement for the
superfluous intermediary partitions node. This patch provides the
added information required for automatic parsing by the core.Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Until now the dynamically configurable message sequences for read, write
and enable 32bit addressing have been global. Brian makes a good point
why this should not be the case. If there are ever two FSM's located on
the same platform, we could be potentially introducing a race condition
on "needlessly shared data".Suggested-by: Brian Norris
Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
This patch allows us to prepare some of the message sequences which will
be required to talk to the S25FLxxx family of Serial Flash devices. It
also allows us to do some required extra operations after any busy wait
failures.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
When an erase is requested by userspace the MTD framework calls back
into the driver to conduct the actual command issue. Here we provide the
routines which do exactly that. We can choose to either do an entire chip
erase or by sector.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
When we write data to the Serial Flash chip we'll wait a predetermined
period of time before giving up. During that period of time we poll the
status register until completion.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
When we write data to the FIFO the FSM Controller subsequently writes
that data out to the Serial Flash chip.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
When a read is issued by userspace the MTD framework calls back into
the driver to conduct the actual command issue and data extraction.
Here we provide the routines which do exactly that.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Most chips require a predefined set of FSM message sequences for read,
write and erase operations. This patch provides a way to set them up,
which it will do so if a chip specific initialisation routine isn't
been provided.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
In the FSM driver we handle chip differences by providing the possibility
of calling back into a chip specific initialisation routine. In this patch
we provide one for the N25Qxxx series, which endeavours to setup things
like the read, write and erase sequences, as they differ from the
default. We also configure 32bit support and the amount of dummy cycles to
use.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
The N25Qxxx Serial Flash devices required different sequence
configurations depending on whether they're running in 24bit (3Byte)
or 32bit (4Byte) mode. We provide those here.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Message sequences can vary depending on how many pads (lines) are
required to address the chip (mode & dummy), how many data pads (lines)
are required to write out to the chip which will determine speed
amongst other things which are detailed by the SFDP specification. We
are able to use multiple configurations for each chip, but they need
to me matched to a device's capabilities. These configurations are
listed in preference order - most preferred first.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
The FSM Serial Flash Controller is driven by issuing a standard set of
register writes we call a message sequence. This patch supplies a method
to prepare the message sequence responsible for updating a chip's VCR.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Most Serial Flash chips support 24bit addressing as a default but more
recent incarnations can support 32bit. Based on information provided
though platform specific data and capabilities we can determine whether
or not our current chip can. This patch provides a means to setup the
FSM message sequence to put the chip into 32bit mode.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Based on information we can obtain though platform specific data and/or
chip capabilities we are able to determine whether or not we can handle
a SoC reset or not. To find out why this is important please read the
comment provided in the patch.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Firstly we search for our preference read/write configuration based on a
given chip's capabilities. Then we actually set up the message sequence
accordingly.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
The FSM Serial Flash Controller is driven by issuing a standard set of
register writes we call a message sequence. This patch supplies a method
to prepare the message sequence responsible for setting 32bit addressing
mode on the Flash chip.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
The FSM Serial Flash Controller is driven by issuing a standard set of
register writes we call a message sequence. This patch supplies a method
to prepare the message sequence responsible for erasing a single sector.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
It's important for us to determine which device was used to boot from in
order to make some correct decisions surrounding Power Management. On
each of the platforms which support the FSM this is communicated via
a set of mode pins held in the system configuration area. This patch
determine the boot device and stores the result.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
The FSM Serial Flash Controller is driven by issuing a standard set of
register writes we call a message sequence. This patch supplies a method
to prepare read/write FSM message sequence(s) based on chip capability
and configuration.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris -
Take some known parameters, namely size and number of sectors and use
them to determine weather a device can support 32bit addressing or not.
If it can, set the associated flash capability flag for latter use.Acked-by Angus Clark
Signed-off-by: Lee Jones
Signed-off-by: Brian Norris
