ELM hardware can process up to maximum of 8 hannels in parallel for
ECC error detection. Currently the number of channels getting configured for
processing is static determined by macro ERROR_VECTOR_MAX. However, the actual
number of channels that need to be processed is the ECC step number.
This patch just avoids configuring extra unused channels.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Reviewed-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch refactors elm_load_syndrome() to make it scalable for newer
ECC schemes by removing scheme specific macros (like ECC_BYTES*xx),
and instead using ECC control information passed during elm_config.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Reviewed-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

ELM hardware engine is used by BCH ecc-schemes for detecting and locating ECC
errors. This patch adds the following checks for ELM hardware engine:

 - ELM internal buffers are of 1K,
   so it cannot process data with ecc-step-size > 1K.

 - ELM engine can execute upto maximum of 8 threads in parallel,
   so in *page-mode* (when complete page is processed in single iteration),
   ELM cannot support ecc-steps > 8.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Reviewed-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Reported-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Reported-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Reported-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Reported-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Reported-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
[Brian: tweaked a bit]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NBrian Norris <computersforpeace@gmail.com>
Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

When we write data to the FIFO the FSM Controller subsequently writes
that data out to the Serial Flash chip.

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Cc: devicetree@vger.kernel.org
Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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 <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Here we provide a means to traverse though all supplied FSM message
sequence configurations and pick one based on our chip's capabilities.
The first one we match will be the preferred one, as they are
presented in order of preference.

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Using previously added infrastructure we can now extract a device's JEDEC
ID, compare it to a list of known and supported devices and make assumptions
based on known characteristics of a given chip.

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Supply a lookup table of all the devices we intend to support. This table
is used to store device information such as; a human readable device name,
their JEDEC ID (plus the extended version), sector size and amount, a bit
store of a device's capabilities, its maximum running frequency and
possible use of a per-device configuration call-back.

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

JEDEC have helped to standardise a great deal of the commands which
can be issued to a Serial Flash devices. Many of the Serial Flash
Discoverable Parameters (SFDP) commands are generic across devices.
This patch provides a shared point where these commands can be
defined.
Suggested-by: NMark Brown <broonie@kernel.org>
Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Once we start supporting devices it will be handy go detect them
dynamically. This will be done using the chip's unique JEDEC ID. This
patch allows us to extract a device's JEDEC ID using the a predefined
FSM register write sequence.

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

When invoked the driver will attempt to read any available data from
the FSM's data register. Any data collected from this FIFO would have
originated from the flash chip.

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The FSM hardware works by setting a predetermined sequence of register
writes. Rather than open coding them inside each functional block we're
going to define them in a series of formatted 'sequence structures'.
This patch provides the framework which shall be used for every action.

Acked-by Angus Clark <angus.clark@st.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>