> -----Original Message----- > From: Marc Kleine-Budde [mailto:mkl@xxxxxxxxxxxxxx] > Sent: Tuesday, July 31, 2018 12:58 PM > To: Pankaj Bansal <pankaj.bansal@xxxxxxx>; linux-can@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 4/6] net: can: flexcan: Add provision for variable > payload size > > On 07/31/2018 08:23 AM, Pankaj Bansal wrote: > >> -----Original Message----- > >> From: Marc Kleine-Budde [mailto:mkl@xxxxxxxxxxxxxx] > >> Sent: Monday, July 30, 2018 8:51 PM > >> To: Pankaj Bansal <pankaj.bansal@xxxxxxx>; linux-can@xxxxxxxxxxxxxxx > >> Subject: Re: [PATCH 4/6] net: can: flexcan: Add provision for > >> variable payload size > >> > >> On 07/30/2018 05:03 PM, Pankaj Bansal wrote: > >>>>> Till now the flexcan module supported 8 byte payload size as per > >>>>> CAN > >>>>> 2.0 specifications. > >>>>> But now upcoming flexcan module in NXP LX2160A SOC supports > CAN > >> FD > >>>>> protocol too.The Message buffers need to be configured to have > >>>>> payload size greater than 8 bytes (if flexcan module supports it) > > BTW: please update the "FLEXCAN hardware feature flags" table in the > driver, add a CAN-FD column, too. Ok. I have a question though. Should we still call these "QUIRKS"? It gives an impression that there is something wrong with the SOC which has this "QUIRK". > > >>>>> Therefore, added provision in the driver for payload size to be > variable. > >>>>> BUT, limit the only possible payload value to be 8, because the > >>>>> CAN FD changes are not in place yet. > >>>> > >>>> What's the size of a CAN-FD mailbox? Is it fixed or configurable at > >> runtime? > >>> > >>> Flexible mailboxes configurable to store 0 to 8, 16, 32 or 64 bytes > >>> data length > >> > >> Does it make any sense to store less than 64 bytes of data? What's > >> the total size of the mailbox then? > > > > IMO this makes sense in one scenario: if all the nodes in can network > > transmit data with < 64 bytes payload (say 32 bytes), then it would be > > beneficial to limit the payload size to 32 bytes, as this would > > increase number of RX buffers, which would help in reception speed. > > I don't think this will make a big impact in reception speed, but relaxes the > timing constraints instead. > > > The total size of mailbox is Payload + 8 bytes (4 bytes for CAN ID and > > 4 bytes for CAN control bits; same as CAN 2.0 MB) > > > The mailbox are allocated in memory as below: > > Address offset (hex) (8 byte payload) Address offset (hex) (16 byte > > payload) Address offset (hex) (32 byte payload) Address offset (hex) > > (64 byte payload) > > This does look quite complex and could result in ugly code. First thing is to > have a function that converts from mailbox number to mailbox address. > Agreed. I will send the V2 of patches with these changes. Also I will send a RFC patch for CAN FD protocol changes that I am still working on (NOT ready yet). It should help in understanding the context of these patches and how I plan to use these changes in FD mode. > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Industrial Linux Solutions | Phone: +49-231-2826-924 | > Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | > Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
