Hi @carlo.broker...@dlr.de <carlo.broker...@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.broker...@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 <fishesprasha...@gmail.com> > *Gesendet:* Mittwoch, 1. März 2023 11:53 > *An:* Brokering, Carlo <carlo.broker...@dlr.de> > *Cc:* devel@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 (fishesprasha...@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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
