Re: [PATCH 2/3] can: c_can: Provide generic interface to configure c-can message objects

[Wolfgang Grandegger <wg@grandegger.com>]

On 12/20/2012 12:06 PM, Bhupesh SHARMA wrote:
>> On 12/20/2012 3:56 PM, Wolfgang Grandegger wrote:
>>> On 12/20/2012 11:05 AM, Amit Virdi wrote:
>>>> Depending on the underlying platform, the configuration of the c-can
>>>> message objects can change. For e.g. in some systems, it makes more
>>>> sense to receive many message objects and transmit very few. In any
>>>> case, providing flexibility in configuring the message objects is
>>>> highly desirable.
>>>>
>>>> The total number of message objects for C_CAN controller is fixed at 32.
>>>> The receive message objects are assigned higher priority so they
>>>> begin with message object#1. So, in order to configure the message
>>>> object the driver just needs two parameters - rx_split (for
>>>> differentiating between lower bucket and higher bucket) and tx_num.
>>>
>>> What is your motivation to make this configurable?
>>> Why is the current default not good enough?
>>
>> By default the number of receive message objects is kept equal to the
>> number of transmit message objects (16). However, we had some practical
>> use cases in which it was expected that the controller would receive more
>> number of message objects than it would transmit. The current configuration
>> didn't result in an efficient behavior. Maybe, Bhupesh can elaborate this
>> point in more detail.
>>
> 
> Yes. We actually had this requirement from one of our customer whose use-case involved
> the SPEAr MPU to be a master controlling a processing line having a number of CAN devices. In such a case
> there was a specific requirement to have more Rx objects than Tx ones.

OK.

> I believe this is a good feature to keep, otherwise we always have the default option of 
> having equal msg objects for Tx and Rx purposes (16 each).

We need to improve the RX handling anyway similar to Marc's at91_can
driver. There 24 objects are used for RX and 8 for TX.

Wolfgang.