On Sun, 8 May 2022 at 01:51, Ondrej Ille <ondrej.ille@xxxxxxxxx> 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
