Re: [PATCH v1 0/4] can: ctucanfd: clenup acoording to the actual rules and documentation linking

On Sun, 8 May 2022 at 01:51, Ondrej Ille [off-list ref] wrote:

Hello all,

again, sorry for the late reply, my daily job keeps me very busy, and the vision of completely new silicon
coming to our office if we meet a tape-out date is somehow motivating :)

Just few notes about the discussion:

1. Number of TXT Buffers
I agree that driver should read-out this information from the HW, not rely on fixed configuration.
True, the default value in HW master is 2, but Linux driver had 4 hard-coded. This was coming from
times when there were only 4 buffers (no genericity in the HW). IMHO this is HW bug, because the
intention when doing the "arbitrary number of buffers" extension, was to keep default value the
same as in previous implementation. System architecture document also has "4" as value of txt_buffer_count generic.

I will fix this ASAP in the master branch, hopefully regression will not complain so that the current driver
version is compatible with default HW.

As per reading out number of TXT Buffers from HW, Pavel proposed moving TXTB_INFO else-where
so that there is more space for TX_COMMAND in the same memory word. The rationale here, is having
reserve in case of an increasing number of TXT Buffers.

But, with the current format of TX_COMMAND, the reserve would be up to 24 TXT Buffers. Even if there
ever was a use-case for more than 8 buffers, there would need to be another non-compatible changes
in TX_PRIORITY and TX_STATUS, and the whole register map would anyway not be backwards compatible...
So, I propose to keep TXTB_INFO in its current location.

Hi Ondrej,

Based on this it seems my patches can be cleaned up for merging.

Pavel / Odjrej: did you want to include the patches in your public
driver tree and submit from there, or shall I submit them? Adding to
yoru tree would keep it in sync with the upstream driver already
submitted. If you provide a review I'll cleanup any issues reported. I
can submit directly to Linux as Marc proposed but having a single
authoritative source seems cleanest to me.

My current patches are on master in this tree:
https://github.com/AndrewD/ctucanfd_ip_core

I'll add "Signed-off-by: " to the commit messages next time I touch
this - once I get clarity on the way forward. I don't have an
immediate need for a Linux driver for ctucanfd so haven't touched this
recently.

Kind regards,

Andrew