Hello Martin,
thanks for the contribution!
Unfortunately [PATCH 2/2] only hit the devicetree mailing list but not
the linux-can mailing list for the review.
Btw. I already have two questions from the description:
On 11/24/2017 07:35 PM, kernel@xxxxxxxxxxxxxxxx wrote:
(..)
The driver has been heavily optimized so that it can handle
a 100% utilized 1MHz Can-bus (with 11 bit can frames with DLC=0)
even on less powerfull SOCs like the raspberry pi 1 without
dropping frames due to driver/spi latencies
(..)
> The driver implements a lock-less design for transmissions
> making use instead of prepared spi messages submitted via spi_async
> for transmission in the start_xmit_start code without requireing
> an extra workqueue and the corresponding latencies.
Seems you improved the SPI handling here. Would it make sense to
separate the SPI-related part of the code to a separate C-file so that
the existing mcp251x driver can benefit from these improvements too?
(still dropps are observed in the can/network stack).
Are you sure drops are taking place in the network layer? Can you give
me some more details about this statement?
Best regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
