SPI driver runtime error messages: check_response: mcp2210 command failed (status = 0xf8) (device busy)

[CajusH]

Hi,

I am using your MCP2210 driver with my Kernel 4.4.10 on an i.MX6 design.
I have two MCP2210 in my design, both chips drive SPI devices.
I monitored the SPI communication and found out, that after 60 bytes on the SPI there is a long delay (19ms and more)
The attached screenshot shows a transfer of 260 bytes (4 blocks with 60 bytes and one with 20 bytes)

Do you have an explanation for this and maybe a solution to get rid of the delays?
We typically have larger data blocks then 60 bytes.

Depending on the clock I also see error messages:

Transfer 260 bytes
spi mode: 0
bits per word: 8
max speed: 100000 Hz (100 KHz)
usb 2-1.2: check_response: mcp2210 command failed (status = 0xf8)
usb 2-1.2: report_status_error: status 0xf8: device busy
usb 2-1.2: spi_mcp_error: cmd->busy_count 0
usb 2-1.2: complete_urb: ignoring mcp_status error and repeating
usb 2-1.2: check_response: mcp2210 command failed (status = 0xf8)
usb 2-1.2: report_status_error: status 0xf8: device busy
usb 2-1.2: spi_mcp_error: cmd->busy_count 1
usb 2-1.2: complete_urb: ignoring mcp_status error and repeating
usb 2-1.2: check_response: mcp2210 command failed (status = 0xf8)
usb 2-1.2: report_status_error: status 0xf8: device busy
usb 2-1.2: spi_mcp_error: cmd->busy_count 2
usb 2-1.2: complete_urb: ignoring mcp_status error and repeating
usb 2-1.2: check_response: mcp2210 command failed (status = 0xf8)
usb 2-1.2: report_status_error: status 0xf8: device busy
usb 2-1.2: spi_mcp_error: cmd->busy_count 3
usb 2-1.2: complete_urb: ignoring mcp_status error and repeating

It looks like the number of error message correspond to the number transferred bytes and the clock.
If I use a higher clock (more than 430kHz) I will not get the errors for my 260 byte transfer,
but I will get an error, if I transfer 460 bytes with the 430kHz clock.

Any idea, how to get rid of the error messages?

Best Regards
Cajus

[daniel-santos]

I'm really sorry I missed this message. This is because I've written a supreme driver for a shitty device. I have some local commits that better tunes this, but on the order of +20% performance. I'm going to continue maintaining this driver and get those improvements committed once I clean up and test better, but it's just a falsely advertised product!

[jhausladen]

@daniel-santos Were there any updates on this? At least, I still get a lot of those error messages, flooding the kernel logs...
spi_mcp_error: cmd->busy_count 0
complete_urb: ignoring mcp_status error and repeating

[CajusH]

I simply commended-out the corresponding lines as the warning seems to appear on every message > 60 bytes long, even if the data was transferred.