06 Feb, 2020
1 commit
-
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass
03 Dec, 2019
2 commits
-
These functions are CPU-related and do not use driver model. Move them to
cpu_func.hSigned-off-by: Simon Glass
Reviewed-by: Daniel Schwierzeck
Reviewed-by: Tom Rini -
This function belongs in time.h so move it over and add a comment.
Signed-off-by: Simon Glass
Reviewed-by: Tom Rini
31 Oct, 2019
2 commits
-
Change the stack-allocated buffer for the identification command
to explicitly allocate page-aligned buffers. Even though the spec
seems to allow having admin queue commands on non page-aligned
buffers, it seems to not be possible on my i.MX8MQ board with a
a Silicon Power P34A80. Since all of the NVMe drivers I have seen
always do admin commands on a page-aligned buffer, which does work
on my system, it makes sense for us to do that as well.Signed-off-by: Patrick Wildt
Reviewed-by: Bin Meng -
It's possible that the data cache for the buffer still holds data
to be flushed to memory, since the buffer was probably used as stack
before. Thus we need to make sure to flush it also on reads, since
it's possible that the cache is automatically flused to memory after
the NVMe DMA transfer happened, thus overwriting the NVMe transfer's
data. Also add a missing dcache flush for the prp list.Signed-off-by: Patrick Wildt
Reviewed-by: Bin Meng
06 Oct, 2019
1 commit
-
This adds a function which can be used by e.g. EFI to retrieve
the namespace identifier and EUI64. For that it adds the EUI64
to its driver internal namespace structure and copies the EUI64
during namespace identification.Signed-off-by: Patrick Wildt
Tested-by: Heinrich Schuchardt
Reviewed-by: Bin Meng
26 Aug, 2019
1 commit
-
When large writes take place I saw a Samsung EVO 970+ return a status
value of 0x13, PRP Offset Invalid. I tracked this down to the
improper handling of PRP entries. The blocks the PRP entries are
placed in cannot cross a page boundary and thus should be allocated
on page boundaries. This is how the Linux kernel driver works.With this patch, the PRP pool is allocated on a page boundary and
other than the very first allocation, the pool size is a multiple of
the page size. Each page can hold (4096 / 8) - 1 entries since the
last entry must point to the next page in the pool.Signed-off-by: Aaron Williams
Reviewed-by: Bin Meng
19 May, 2019
1 commit
-
When dma_addr_t is u32 in 64-bit, there are some warnings when
building NVME driver. Fix it by doing an additional (long) cast.Signed-off-by: Bin Meng
15 Nov, 2018
1 commit
-
part_init() is currently called in every DM BLK driver, either
in its bind() or probe() method. However we can use the BLK
uclass driver's post_probe() method to do it automatically.Update all DM BLK drivers to adopt this change.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
07 May, 2018
1 commit
-
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.Signed-off-by: Tom Rini
09 Feb, 2018
1 commit
-
config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE
based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to
Kconfig allows us to drastically shrink the logic in
config_fallbacks.hSigned-off-by: Adam Ford
[trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE]
Signed-off-by: Tom Rini
04 Sep, 2017
3 commits
-
Execution cannot reach this statement: "nr_io_queues = result;"
Reported-by: Coverity (CID: 166731)
Signed-off-by: Bin Meng
Reviewed-by: Tom Rini -
"lbas" with type "u16" (16 bits, unsigned) is promoted in
"lbas << ns->lba_shift" to type "int" (32 bits, signed), then
sign-extended to type "unsigned long long" (64 bits, unsigned).
If "lbas << ns->lba_shift" is greater than 0x7FFFFFFF, the upper
bits of the result will all be 1.Fix it by casting "lbas" to "u32".
Reported-by: Coverity (CID: 166730)
Signed-off-by: Bin Meng
Reviewed-by: Tom Rini -
memset() was given a sizeof(NVME_Q_NUM * sizeof(struct nvme_queue *)
to clear, which is wrong.Reported-by: Coverity (CID: 166729)
Signed-off-by: Bin Meng
Reviewed-by: Tom Rini
28 Aug, 2017
11 commits
-
At present the NVMe uclass driver uses a global variable nvme_info
to store global information like namespace id, and NVMe controller
driver's priv struct has a blk_dev_start that is used to calculate
the namespace id based on the global information from nvme_info.This is not a good design in the DM world and can be replaced with
the following changes:- Encode the namespace id in the NVMe block device name during
the NVMe uclass post probe
- Extract the namespace id from the device name during the NVMe
block device probe
- Let BLK uclass calculate the devnum for us by passing -1 to
blk_create_devicef() as the devnumSigned-off-by: Bin Meng
-
The codes in nvme_uclass_post_probe() can be replaced to call the
blk_create_devicef() API directly.Signed-off-by: Bin Meng
-
So far cache operations are only applied on the submission queue and
completion queue, but they are missing in other places like identify
and block read/write routines.In order to correctly operate on the caches, the DMA buffer passed
to identify routine must be allocated properly on the stack with the
existing macro ALLOC_CACHE_ALIGN_BUFFER().Signed-off-by: Bin Meng
-
The NVMe block read and write routines are almost the same except
the command opcode. Let's consolidate them to avoid duplication.Signed-off-by: Bin Meng
-
NVMe driver only uses two queues. The first one is allocated to do
admin stuff, while the second one is for IO stuff. So far the driver
uses magic number (0/1) to access them. Change to use macros.Signed-off-by: Bin Meng
-
So far the driver unconditionally delays 10ms when en/disabling the
controller and still return 0 if 10ms times out. In fact, spec defines
a timeout value in the CAP register that is the worst case time that
host software shall wait for the controller to become ready.Signed-off-by: Bin Meng
-
Capabilities register is RO and accessed at various places in the
driver. Let's cache it in the controller driver's priv struct.Signed-off-by: Bin Meng
-
So far this is not causing any issue due to NVMe and x86 are using
the same endianness, but for correctness, it should be fixed.Signed-off-by: Bin Meng
-
ndev->queues is a pointer to pointer, but the allocation wrongly
requests sizeof(struct nvme_queue). Fix it.Signed-off-by: Bin Meng
-
The codes currently try to read PCI vendor id of the NVMe block
device by dm_pci_read_config16() with its parameter set as its
root complex controller (ndev->pdev) instead of itself. This is
seriously wrong. We can read the vendor id by passing the correct
udevice parameter to the dm_pci_read_config16() API, however there
is a shortcut by reading the cached vendor id from the PCI device's
struct pci_child_platdata.While we are here fixing this bug, apparently the quirk stuff handle
codes in nvme_get_info_from_identify() never takes effect since its
logic has never been true at all. Remove these codes completely.Signed-off-by: Bin Meng
-
These are leftover when the driver was ported from Linux and are not
used by the U-Boot driver.Signed-off-by: Bin Meng
14 Aug, 2017
5 commits
-
Maximum Data Transfer Size (MDTS) field indicates the maximum
data transfer size between the host and the controller. The
host should not submit a command that exceeds this transfer
size. The value is in units of the minimum memory page size
and is reported as a power of two (2^n).The spec also says: a value of 0h indicates no restrictions
on transfer size. On the real NVMe card this is normally not
0 due to hardware restrictions, but with QEMU emulated NVMe
device it reports as 0. In nvme_blk_read/write() below we
have the following algorithm for maximum number of logic
blocks per transfer:u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
dev->max_transfer_shift being 0 will for sure cause lbas to
overflow. Let's use 20. With this fix, the NVMe driver works
on QEMU emulated NVMe device.Signed-off-by: Bin Meng
Reviewed-by: Tom Rini -
NVMe should use the nsze value from the queried device. This will
reflect the total number of blocks of the device and fix detecting
my Samsung 960 EVO 256GB.Original:
Capacity: 40386.6 MB = 39.4 GB (82711872 x 512)Fixed:
Capacity: 238475.1 MB = 232.8 GB (488397168 x 512)Signed-off-by: Jon Nettleton
Reviewed-by: Bin Meng
Tested-by: Bin Meng
Reviewed-by: Tom Rini -
This adds support to detect the catchall PCI class for NVMe devices.
It allows the drivers to work with most NVMe devices that don't need
specific detection due to quirks etc.Tested against a Samsung 960 EVO drive.
Signed-off-by: Jon Nettleton
Signed-off-by: Bin Meng
Reviewed-by: Tom Rini -
This adds nvme_print_info() to show detailed NVMe controller and
namespace information.Signed-off-by: Zhikang Zhang
Signed-off-by: Wenbin Song
Signed-off-by: Bin Meng
Reviewed-by: Tom Rini -
NVM Express (NVMe) is a register level interface that allows host
software to communicate with a non-volatile memory subsystem. This
interface is optimized for enterprise and client solid state drives,
typically attached to the PCI express interface.This adds a U-Boot driver support of devices that follow the NVMe
standard [1] and supports basic read/write operations.Tested with a 400GB Intel SSD 750 series NVMe card with controller
id 8086:0953.[1] http://www.nvmexpress.org/resources/specifications/
Signed-off-by: Zhikang Zhang
Signed-off-by: Wenbin Song
Signed-off-by: Bin Meng
Reviewed-by: Tom Rini
