All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: "AnilKumar, Chimata" <anilkumar@ti.com>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
	"socketcan@hartkopp.net" <socketcan@hartkopp.net>,
	"m.kleine-budde@pengutronix.de" <m.kleine-budde@pengutronix.de>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Gole, Anant" <anantgole@ti.com>, "Nori, Sekhar" <nsekhar@ti.com>
Subject: Re: [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller
Date: Tue, 03 Apr 2012 17:33:40 +0200	[thread overview]
Message-ID: <4F7B1854.90106@pengutronix.de> (raw)
In-Reply-To: <331ABD5ECB02734CA317220B2BBEABC1317D86F7@DBDE01.ent.ti.com>

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

On 04/03/2012 04:29 PM, AnilKumar, Chimata wrote:
>>>> Please explain why this CAN controller cannot be handled by the existing
>>>> C_CAN driver, eventually with some extensions. The register layout seems
>>>> almost identical, at least.
>>>>
>>>> Wolfgang.
>>>>
>>>
>>> These are the some of the pointers I can say, why I had gone for separate
>>> file instead of existing driver:
>>> * In case of D_CAN driver we can see all the registers are 32bit length
>>>   but in case of C_CAN registers are in 16bit length.
>>
>> How many bits in these 32 bit registers are used?
> 
> In some cases (D_CAN_TXRQ, D_CAN_INTPND, D_CAN_MSGVAL) I have used all the
> bits, in some cases used few bits.
> 
> Roughly I can say that its (higher 16bits) % of usages is similar as compare
> to 16bits 
> 
> While checking the status of TXRequest registers and INT pending register,
> which is a hot code path, we have to put if checks for register access.

The c_can already has a c_can_read_reg32() function. It's for example
used in the rx_poll function. You can make it a function pointer (i.e.
pric->read_reg32()) for easy abstraction.

>>> * Some of the registers, bit masks are different, so we have to add
>>>   checks on every API for differentiating the kind of device
>>
>> Which registers are this? Can you give us an example?
> 
> I am pointing out some of the resisters
> * Single registers in case of D_CAN but multiple register in case of C_CAN
>   So masks will change MASK, ARB, INTPND
> * D_CAN_IFCMD is the combination of COMM request and COMM mask registers

Maybe you can use the read_reg32 function on both c_can and d_can.

regards, 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   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2012-04-03 15:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-03 12:32 [PATCH] ARM: OMAP: AM33XX: CAN: d_can: Add support for Bosch D_CAN controller AnilKumar Ch
2012-04-03 12:32 ` AnilKumar Ch
2012-04-03 12:39 ` AnilKumar, Chimata
2012-04-03 15:54   ` Oliver Hartkopp
2012-04-03 18:07     ` AnilKumar, Chimata
2012-04-03 12:44 ` Wolfgang Grandegger
2012-04-03 12:49   ` Marc Kleine-Budde
2012-04-03 13:41   ` AnilKumar, Chimata
2012-04-03 13:49     ` Marc Kleine-Budde
2012-04-03 14:29       ` AnilKumar, Chimata
2012-04-03 15:33         ` Marc Kleine-Budde [this message]
2012-04-03 15:58           ` AnilKumar, Chimata
2012-04-04  3:43             ` Bhupesh SHARMA
2012-04-04 16:21             ` Wolfgang Grandegger
2012-04-05 14:15               ` AnilKumar, Chimata
2012-04-05 14:20                 ` Gary Thomas
2012-04-05 15:54                   ` Gole, Anant
2012-04-05 16:00                     ` Gary Thomas

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=4F7B1854.90106@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=anantgole@ti.com \
    --cc=anilkumar@ti.com \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=m.kleine-budde@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=socketcan@hartkopp.net \
    --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.