since mmap may exist in block_operations, but truncate may not,
moving mmap beforee truncate could make three struct more compatible
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
- Add mmap into file_operations and remove it from ioctl definitions.
- Add mm_map structure definitions to support future unmapping
- Modify all drivers to initialize the operations struct accordingly
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
- Add truncate into file_operations
- Move truncate to be common for mountpt_operations and file_operations
- Modify all drivers to initialize the operations struct accordingly
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
In the past, header file paths were generated by the incdir command
Now they are generated by concatenating environment variables
In this way, when executing makefile, no shell command will be executed,
it will improve the speed of executing makfile
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
This patch introduces a configuration option USBMSC_WRMULTIPLE,
which is used to store multiple blocks into a larger chunk that
then gets written via the mmcsd_writemultiple() (in case mmcsd
is used).
The bottleneck with the current implementation is the poor
performance due to short block writes. USBMSC_DRVR_WRITE()
always writes only one sector (with eMMC that's usually 512 bytes).
eMMC devices usually erase much larger regions with near constant
time (see Jedec JESD84-B51, Extended CSD register byte [225],
SUPER_PAGE_SIZE): 'This register defines one or multiple of
programmable boundary unit that is programmed at the same time.'
If USBMSC_WRMULTIPLE is defined, then USBMSC_NWRREQS is used to
allocate the write buffer size. We don't want this to be the
default behavior yet as this may reveal unseen bugs in usb drivers
due to the faster overall performance.
Sample configurations with measured performance:
- Without USBMSC_WRMULTIPLE: 470 Kb/s
- With USBMSC_WRMULTIPLE, CONFIG_USBMSC_NWRREQS=4: 1.1 Mb/s
(dd with bs=2k)
- With USBMSC_WRMULTIPLE, CONFIG_USBMSC_NWRREQS=16: 5.2 Mb/s
(dd with bs=8k)
No doubt, this feature alone may make the mass storage work 10
times faster than before with eMMC cards.
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
usbmsc.h uses the CONFIG_USBMSC_IFNOBASE configuration option,
but it cannot be set anywhere. Provide means to configure this
option which is useful when it's other than the default zero.
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
iSerialNumber field in the device descriptor can be used to determining the
board when multiple boards connected to the same host. So add feature to change
serial string by board unique ID dynamically.
To use this feature, user must be implement the board_usbdev_serialstr() logic.
refs #13909
The new configuration CONFIG_USBMSC_NOT_STALL_BULKEP avoids to go into
stall state when :
- Receiving SCSI_CMD_INQUIRY with flags or pagecode != 0
- Receiving SCSI_CMD_MODESENSE6 and return the result data shorter than
the requested data size.
Instead of stall, it just ignores the error condition.
Originally the usb driver goes into the stall under the conditions
mentioned above to inform to the USB host that the requested SCSI feature
is not supported, or the result data is shorter than the requested data
size.
But, at this moment, RP2040 USB device driver cannot handle entering and
leaving stall state of the bulk endpoints well. Once stalls, the host -
device communication stops and cannot be resumed.
I have investigated to solve the issue and found that the existing
RP2040 USB device driver implementation, TinyUSB
(https://github.com/hathach/tinyusb) mass-storage class driver doesn't
enter the stall state like the treatment of this patch.
So, I introduce this new configuration as the RP2040 workaround.
In the future, when the RP2040 USB device driver is fixed and can handle
the bulk endpoint stall correctly, this patch should be reverted.
Gregory Nutt is the copyright holder for those files and he has submitted the
SGA as a result we can migrate the licenses to Apache.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
