Re: [PATCH v2 1/3] can: ctucanfd: add HW timestamps to RX and error CAN frames

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Marc,

On Wednesday 03 of August 2022 11:04:36 Marc Kleine-Budde wrote:
> On 02.08.2022 09:37:54, Pavel Pisa wrote:
> > See 2.14.1 Loopback mode
> > SETTINGS[ILBP]=1.
> >
> > in the datasheet
> >
> >   http://canbus.pages.fel.cvut.cz/ctucanfd_ip_core/doc/Datasheet.pdf
>
> BTW: the datasheet says:
> | 3.1.36 RX_DATA
> |
> | ... this register must be read by 32 bit access.
>
> While there is a section that uses 8-bit accessed on that register:

Congratulation to watchfull reading.

The FPGA design is done so that 32, 16 and 8-bits read writes
are supported. But when you read only part of the RX data
register then you lose rest because FIFO advances to the next
32-bit word. That is reasonable solution for 32-bit systems.

There has been added option in 3.0 version to switch into mode
where FIFO doe not advance when RX_DATA is read, then you can
read it by 8 or 16 bits. If MODES[RXBAM]=0 is set. Then advance
to the next world is requested by COMMAND[RXRPMV] bit.
Ondrej Ille considered that mode for for some embedded
use of the core connected to some small MCU. But this
mode causes great overhead in the driver, multiple reads
of RX_DATA followed by write to to COMMAND. I would consider
only default 32-bit mode for Linux driver.  

In the fact, to connect to 16-bit systems, my preference would
be to add option into design to select if Rx FIFO advances
by read of LSB or MSB of the RX_DATA register.

Anyway, command register needs at least 16-bit accesses
for now to correctly command operation, for 8-bit it would
require catch one written byte into latch and combine
it with another one written to the other part and this
would require locking around each command write...

For priority register we need at least 16-bit single write
cycle access when 4 TX buffers are used in FIFO configuration.

I do not intend to complicate driver for all these edge cases
when our target on regular Linux systems is utilize 32-bit
busses...

Actual driver uses only 32-bit access exclusively...

Thanks for the checks and suggestions,

                Pavel
-- 
                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@xxxxxxxxxxxxxxxx
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux