all over the place. Also pass the softc as the arg to all the internal
functions instead of passing a device_t and calling device_get_softc() in
each function.
before starting them.
Using the wait-before logic would make sense if there was useful time-
consuming work that could be done between the end of one write and the
beginning of the next, but it also requires doing the wait-for-ready before
reading, because a prior write or erase could still be in progress. Reading
is the far more common case, so adding a whole extra bus transaction to
check for ready before each read would soak up any small gains that might be
had from doing async writes.
for the same condition that the preceeding lines checked for and would have
returned EIO, so the assert could never possibly trigger (sc_sectorsize must
inherently be an integer multiple of FLASH_PAGE_SIZE).
transfers data in both directions at once. When writing to the device,
use a dummy buffer for the incoming data, not the same buffer as the
outgoing data. Writes are done in FLASH_PAGE_SIZE chunks, which is only
256 bytes, so just put the dummy buffer into the softc.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
If we cannot establish compatibility by only looking at the compat_data we
also check the flash_devices structure's names for a compatible device.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D6026
No functional change, only trivial cases are done in this sweep,
Drivers that can get further enhancements will be done independently.
Discussed in: freebsd-current
A lot of dts files define the SPI flashes supported by mx25l as
compatible with 'jedec,spi-nor', so we add this to the mx25l
compat_data.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5962
Introduce 2 new flags:
- FL_ENABLE_4B_ADDR (forces the use of 4-byte addresses)
- FL_DISABLE_4B_ADDR (forces the use of 3-byte addresses)
If an SPI flash chip is defined with FL_ENABLE_4B_ADDR in its flags,
then an 'Enter 4-byte mode' command is sent to the chip at attach time
and, later, all commands that require addressing are issued with 4-byte
addresses.
If an SPI flash chip is defined with FL_DISABLE_4B_ADDR in its flags,
then an 'Exit 4-byte mode' command is sent to the chip at attach time
and, later, all commands that require addressing are issued with 3-byte
addresses.
For chips that do not have any of these flags defined the behaviour is
unchanged.
This change also adds support for the MX25L25735F and MX25L25635E chips
(vendor id 0xc2, device id 0x2019), which support 4-byte mode and enables
4-byte mode for them. These are 256Mbit devices (32MiB) and, as such, can
only be fully addressed by using 4-byte addresses.
Approved by: adrian (mentor)
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D5808
This teaches the mx25l driver (sys/dev/flash/mx25l.c) to interact with
sys/dev/fdt/fdt_slicer.c and sys/geom/geom_flashmap.c.
This allows systems with SPI flash to benefit from the possibility to define
flash 'slices' via FDT, just the same way that it's currently possible for
CFI and NAND flashes.
Tested:
* Carambola 2, AR9331 + SPI NOR flash
PR: kern/206227
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
them, please let me know if not). Most of these are of the form:
static const struct bzzt_type {
[...list of members...]
} const bzzt_devs[] = {
[...list of initializers...]
};
The second const is unnecessary, as arrays cannot be modified anyway,
and if the elements are const, the whole thing is const automatically
(e.g. it is placed in .rodata).
I have verified this does not change the binary output of a full kernel
build (except for build timestamps embedded in the object files).
Reviewed by: yongari, marius
MFC after: 1 week
- Make the device description match the driver name.
- Identify the chip variant based on the JEDEC and use that information
to use the proper values for page count, offset and size instead of
hardcoding a AT45DB642x with 2^N byte page support disabled.
- Take advantage of bioq_takefirst().
- Given that CONTINUOUS_ARRAY_READ_HF (0x0b) command isn't even mentioned
in Atmel's DataFlash Application Note, as suggested by the previous
comment may not work on all all devices and actually doesn't properly
on at least AT45DB321D (JEDEC 0x1f2701), rewrite at45d_task() to use
CONTINUOUS_ARRAY_READ (0xe8) for reading instead. This rewrite is laid
out in a way allowing to easily add support for BIO_DELETE later on.
- Add support for reads and writes not starting on a page boundary.
- Verify the flash content after writing.
- Let at45d_task() gracefully handle errors on SPI transfers and the
device not becoming ready afterwards again. [1]
- Use DEVMETHOD_END. [1]
- Use NULL instead of 0 for pointers. [1]
Additional testing by: Ian Lepore
Submitted by: Ian Lepore [1]
MFC after: 1 week
the larger, aligned write+erase sizes the driver currently implements.
This preserves write behaviour but makes the flash driver usable for things
like a read-only FFS or a geom_uzip/geom_compress .
Note that since GEOM will now return the sector size as being smaller,
writes of sector size/alignment will now fail with an EIO. Code which
writes to the flash device will have to be (for now) manually taught
about the flash write blocksize.
to kproc_xxx as they actually make whole processes.
Thos makes way for us to add REAL kthread_create() and friends
that actually make theads. it turns out that most of these
calls actually end up being moved back to the thread version
when it's added. but we need to make this cosmetic change first.
I'd LOVE to do this rename in 7.0 so that we can eventually MFC the
new kthread_xxx() calls.
