CAN driver implementation for Xilinx Zynq

[Prashanth S]

Hi @Carlo.Brokering at dlr.de <Carlo.Brokering at dlr.de> ,

> the design for the rx data path including the RxFIFO looks promising. If
nobody is working on it yet, I would try to implement it. You said it still
needs to be approved -

> who do I have to contact for this?

I saw in discord there was a discussion for the rework of CAN framework, so
you could start a discussion in this mailing list or in discord.

>

> I think you misunderstood me about the ioctl api. My main question was
why command and buffer are not passed to the dev_ioctl here:

>

> bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0);

The ioctl commands are not defined for the CAN framework, so NULL and 0 are
passed to dev_ioctl.


Regards
Prashanth S

On Wed, 1 Mar 2023 at 21:08, <Carlo.Brokering at dlr.de> wrote:

> Hello Prashanth S,
>
>
>
> the design for the rx data path including the RxFIFO looks promising. If
> nobody is working on it yet, I would try to implement it. You said it still
> needs to be approved - who do I have to contact for this?
>
>
>
> I think you misunderstood me about the ioctl api. My main question was why
> command and buffer are not passed to the dev_ioctl here:
>
>
>
> bus->can_dev_ops->dev_ioctl(bus->priv, NULL, 0);
>
>
>
> Regards
>
> Carlo Brokering
>
>
>
> *Von:* Prashanth S <fishesprashanth at gmail.com>
> *Gesendet:* Mittwoch, 1. März 2023 11:53
> *An:* Brokering, Carlo <Carlo.Brokering at dlr.de>
> *Cc:* devel at rtems.org
> *Betreff:* Re: CAN driver implementation for Xilinx Zynq
>
>
>
> Hello @Carlo Brokering,
>
>
>
> > As part of an internship at the German Aerospace Center, I am currently
> working on the implementation of a CAN driver for a Xilinx
>
> > Zynq SoC. For this I used the existing CAN framework /dev/can/can.h. A
> merge request will follow soon.
>
> All the best for your Internship.
>
> >
>
> >
> > Here's what I'd like to add to the framework if it hasn't already been
> done:
> >
> > * RxFIFO. Currently can_bus_read only stores the latest CAN message in
> can_bus->can_rx_msg.
>
> > There is a FIXME note on this in can.c, line 188, but I couldn't find an
> implementation of it.
>
> Currently, the CAN framework has minimal rx support. The design of the rx
> data path in the CAN Framework is ready (You could use that design if
> approved or you can have your own design).
>
>
>
> Note: The tx data path has been implemented, it supports multiple open
> among different tasks, configurable buffers.
>
> >
> > * ioctl functionality. can_bus_ioctl does not forward the commands and
> arguments to can_dev_ops->dev_ioctl.
>
> > Is there a reason for that? I propose a command enum that would provide
> consistency.
>
> The bsp CAN driver should register the ioctl api with the CAN Framework
> for device specific commands (To add commands for hardware independent
> functionality the commands can be added before "if (bus == NULL ||
> bus->can_dev_ops->dev_ioctl == NULL)" statement.
>
>
>
> struct can_dev_ops dev_ops (.dev_ioctl member should be registered).
>
> >
>
> >
> > @Prashanth S (fishesprashanth at gmail.com) have you already worked on
> these points?
>
>
>
> For the overview of the CAN framework, tx, rx, data paths you can refer
> the docs files in the gitlab link (.puml version of the docs are also
> available if you needed (
> https://gitlab.com/slpp95prashanth/gsoc-2022/-/commit/f42e192afefdd94a66456181f9d169f0728d5b4f)
> ).
>
>
>
> You can use the gitlab
> https://gitlab.com/slpp95prashanth/gsoc-2022/-/tree/can-bsp-docs/can-docs
> link for the design documents.
>
>
>
> Regards
>
> Prashanth S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230302/307a6e52/attachment-0001.htm>