All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amit Virdi <amit.virdi@st.com>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
	Bhupesh SHARMA <bhupesh.sharma@st.com>,
	"anilkumar@ti.com" <anilkumar@ti.com>,
	spear-devel <spear-devel@list.st.com>
Subject: Re: [PATCH 2/3] can: c_can: Provide generic interface to configure c-can message objects
Date: Wed, 16 Jan 2013 14:41:39 +0530	[thread overview]
Message-ID: <50F66ECB.8070203@st.com> (raw)
In-Reply-To: <50F66CE3.8070302@grandegger.com>

On 1/16/2013 2:33 PM, Wolfgang Grandegger wrote:
> On 01/16/2013 08:45 AM, Amit Virdi wrote:
>> On 12/21/2012 1:43 AM, Wolfgang Grandegger wrote:
>>> On 12/20/2012 03:04 PM, Marc Kleine-Budde 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.
>>>>>
>>>>> However, if the user doesn't specify these parameters, then the message
>>>>> objects are configured with default parameters with equal distribution
>>>>> of receive and transmit message objects (16 each).
>>>>
>>>> As Wolfgang pointed out, the DT should only describe the hardware. In
>>>> the ethernet world I think there is ethtool to configure the hardware.
>>>> Maybe we need something similar for CAN (or add CAN support to ethtool).
>>>
>>> Yeah, a simple tool using simple ioctl request would be nice, indeed.
>>> Well, as a per device setting seems overkill a simple module parameter
>>> would just do it.
>>>
>>
>> So, you're saying to drop the device configuration from the DT and use
>> some tool to do that. This would be nice if there are enough devices,
>> apart from the Bosch C-CAN controller, which require this sort of
>> configuration.
>
> No, I said: "a simple module parameter would just do it".
>

Ok, now I understood!

Regards
Amit Virdi

  reply	other threads:[~2013-01-16  9:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-20 10:05 [PATCH 0/3] c_can: Update can support Amit Virdi
2012-12-20 10:05 ` [PATCH 1/3] can: c_can: Correct register alignment info passing through DT Amit Virdi
2012-12-20 13:59   ` Marc Kleine-Budde
2013-01-16  7:40     ` Amit Virdi
2012-12-20 10:05 ` [PATCH 2/3] can: c_can: Provide generic interface to configure c-can message objects Amit Virdi
2012-12-20 10:26   ` Wolfgang Grandegger
2012-12-20 10:53     ` Amit Virdi
2012-12-20 11:06       ` Bhupesh SHARMA
2012-12-20 11:12         ` Wolfgang Grandegger
2012-12-20 11:18           ` Amit Virdi
2012-12-20 12:20             ` Wolfgang Grandegger
2012-12-20 14:04   ` Marc Kleine-Budde
2012-12-20 20:13     ` Wolfgang Grandegger
2013-01-16  7:45       ` Amit Virdi
2013-01-16  8:25         ` Bhupesh SHARMA
2013-01-16  9:01           ` Wolfgang Grandegger
2013-01-16  9:03         ` Wolfgang Grandegger
2013-01-16  9:11           ` Amit Virdi [this message]
2012-12-20 10:05 ` [PATCH 3/3] can: c_can: Enable clock before first use Amit Virdi
2012-12-20 14:07   ` Marc Kleine-Budde
2013-01-16  8:03     ` Amit Virdi
2013-01-16  9:54       ` AnilKumar, Chimata
2013-01-16  9:54         ` AnilKumar, Chimata
2013-01-16 13:53         ` Rafael J. Wysocki
2013-01-16 13:53           ` Rafael J. Wysocki
2012-12-20 13:57 ` [PATCH 0/3] c_can: Update can support Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50F66ECB.8070203@st.com \
    --to=amit.virdi@st.com \
    --cc=anilkumar@ti.com \
    --cc=bhupesh.sharma@st.com \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=spear-devel@list.st.com \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.