From: Roger Quadros <rogerq@ti.com>
To: Wolfram Sang <wsa@the-dreams.de>, Marc Kleine-Budde <mkl@pengutronix.de>
Cc: wg@grandegger.com, tony@atomide.com, tglx@linutronix.de,
mugunthanvnm@ti.com, george.cherian@ti.com, balbi@ti.com,
nsekhar@ti.comnm@ti.com, sergei.shtylyov@cogentembedded.com,
linux-omap@vger.kernel.org, linux-can@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
Date: Wed, 1 Oct 2014 13:57:54 +0300 [thread overview]
Message-ID: <542BDE32.6030309@ti.com> (raw)
In-Reply-To: <20141001104317.GB1261@katana>
On 10/01/2014 01:43 PM, Wolfram Sang wrote:
>
>>> Unfortunately it is 5 ;)
>>> We have display IP related bit in between 3 and 5 :P
>>
>> What on earth were the HW engineers thinking????????????
>
> "Let's test my RNG on the bit-placement of this register" :)
:D
>
>> ...if we just have the instance parameter in the syscon phandle, we have
>> to put the mapping into the driver, which makes IMHO no sense, because
>> you have to touch the driver, if there is another SoC with the DCAN core.
My guess is that TI won't come up with a 3rd variant so we won't have to
touch the driver, but you never know for sure.
>
> ... which would be my preferred solution. I think new SoCs should have
> some kind of:
>
> compatible = "commodore,c64ultra", "bosch,d_can";
>
> in the DT anyhow to allow for SoC specific quirks/adjustments. And
> custom raminit belongs to that IMO (see the ti routine getting more and
> more specific).
>
Right. For now we need 2 start/stop definations for the existing TI Socs.
but where to store the raminit start/stop bits? The driver_data currently seems to
contain the CAN type C_CAN vs D_CAN without containing it in a platform_data structure.
Is it OK to create a new platform_data structure for CAN and put the type and raminit start/stop
bits there?
cheers,
-roger
WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq@ti.com>
To: Wolfram Sang <wsa@the-dreams.de>, Marc Kleine-Budde <mkl@pengutronix.de>
Cc: <wg@grandegger.com>, <tony@atomide.com>, <tglx@linutronix.de>,
<mugunthanvnm@ti.com>, <george.cherian@ti.com>, <balbi@ti.com>,
<nsekhar@ti.com>, <nm@ti.com>,
<sergei.shtylyov@cogentembedded.com>,
<linux-omap@vger.kernel.org>, <linux-can@vger.kernel.org>,
<netdev@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
Date: Wed, 1 Oct 2014 13:57:54 +0300 [thread overview]
Message-ID: <542BDE32.6030309@ti.com> (raw)
In-Reply-To: <20141001104317.GB1261@katana>
On 10/01/2014 01:43 PM, Wolfram Sang wrote:
>
>>> Unfortunately it is 5 ;)
>>> We have display IP related bit in between 3 and 5 :P
>>
>> What on earth were the HW engineers thinking????????????
>
> "Let's test my RNG on the bit-placement of this register" :)
:D
>
>> ...if we just have the instance parameter in the syscon phandle, we have
>> to put the mapping into the driver, which makes IMHO no sense, because
>> you have to touch the driver, if there is another SoC with the DCAN core.
My guess is that TI won't come up with a 3rd variant so we won't have to
touch the driver, but you never know for sure.
>
> ... which would be my preferred solution. I think new SoCs should have
> some kind of:
>
> compatible = "commodore,c64ultra", "bosch,d_can";
>
> in the DT anyhow to allow for SoC specific quirks/adjustments. And
> custom raminit belongs to that IMO (see the ti routine getting more and
> more specific).
>
Right. For now we need 2 start/stop definations for the existing TI Socs.
but where to store the raminit start/stop bits? The driver_data currently seems to
contain the CAN type C_CAN vs D_CAN without containing it in a platform_data structure.
Is it OK to create a new platform_data structure for CAN and put the type and raminit start/stop
bits there?
cheers,
-roger
next prev parent reply other threads:[~2014-10-01 10:58 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 14:31 [PATCH v2 0/3] net: can: Use syscon regmap for TI specific RAMINIT register Roger Quadros
2014-09-09 14:31 ` Roger Quadros
2014-09-09 14:31 ` [PATCH v2 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout Roger Quadros
2014-09-09 14:31 ` Roger Quadros
2014-09-09 14:34 ` Marc Kleine-Budde
2014-09-09 14:34 ` Marc Kleine-Budde
2014-09-09 14:39 ` Roger Quadros
2014-09-09 14:39 ` Roger Quadros
2014-09-16 14:13 ` Marc Kleine-Budde
2014-09-16 14:13 ` Marc Kleine-Budde
2014-09-09 14:34 ` Nishanth Menon
2014-09-09 14:34 ` Nishanth Menon
2014-09-09 14:45 ` Roger Quadros
2014-09-09 14:45 ` Roger Quadros
2014-09-09 14:51 ` Nishanth Menon
2014-09-09 14:51 ` Nishanth Menon
2014-09-09 14:54 ` Roger Quadros
2014-09-09 14:54 ` Roger Quadros
2014-09-09 14:31 ` [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism Roger Quadros
2014-09-09 14:31 ` Roger Quadros
2014-09-30 13:26 ` Wolfram Sang
2014-09-30 13:26 ` Wolfram Sang
2014-09-30 13:33 ` Roger Quadros
2014-09-30 13:33 ` Roger Quadros
2014-09-30 13:52 ` Wolfram Sang
2014-09-30 13:52 ` Wolfram Sang
2014-09-30 13:58 ` Roger Quadros
2014-09-30 13:58 ` Roger Quadros
2014-09-30 14:19 ` Wolfram Sang
2014-09-30 14:19 ` Wolfram Sang
2014-09-30 14:22 ` Marc Kleine-Budde
2014-09-30 14:22 ` Marc Kleine-Budde
2014-09-30 14:49 ` Wolfram Sang
2014-09-30 14:49 ` Wolfram Sang
2014-09-30 15:01 ` Marc Kleine-Budde
2014-09-30 15:01 ` Marc Kleine-Budde
2014-09-30 15:25 ` Wolfram Sang
2014-09-30 15:25 ` Wolfram Sang
2014-09-30 16:04 ` Marc Kleine-Budde
2014-09-30 16:04 ` Marc Kleine-Budde
2014-10-01 8:45 ` Roger Quadros
2014-10-01 8:45 ` Roger Quadros
2014-10-01 8:47 ` Marc Kleine-Budde
2014-10-01 8:47 ` Marc Kleine-Budde
2014-10-01 9:06 ` Roger Quadros
2014-10-01 9:06 ` Roger Quadros
2014-10-01 10:01 ` Marc Kleine-Budde
2014-10-01 10:01 ` Marc Kleine-Budde
2014-10-01 10:12 ` Roger Quadros
2014-10-01 10:12 ` Roger Quadros
2014-10-01 10:26 ` Marc Kleine-Budde
2014-10-01 10:26 ` Marc Kleine-Budde
2014-10-01 10:43 ` Wolfram Sang
2014-10-01 10:43 ` Wolfram Sang
2014-10-01 10:57 ` Roger Quadros [this message]
2014-10-01 10:57 ` Roger Quadros
2014-10-01 11:06 ` Marc Kleine-Budde
2014-10-01 11:06 ` Marc Kleine-Budde
2014-10-01 11:10 ` Wolfram Sang
2014-10-01 11:10 ` Wolfram Sang
2014-10-01 11:11 ` Marc Kleine-Budde
2014-10-01 11:11 ` Marc Kleine-Budde
2014-09-30 13:45 ` Marc Kleine-Budde
2014-09-30 13:45 ` Marc Kleine-Budde
2014-09-30 14:02 ` Roger Quadros
2014-09-30 14:02 ` Roger Quadros
2014-09-30 14:11 ` Marc Kleine-Budde
2014-09-30 14:11 ` Marc Kleine-Budde
2014-09-09 14:31 ` [PATCH v2 3/3] net: can: c_can: Add support for START pulse in RAMINIT sequence Roger Quadros
2014-09-09 14:31 ` Roger Quadros
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=542BDE32.6030309@ti.com \
--to=rogerq@ti.com \
--cc=balbi@ti.com \
--cc=george.cherian@ti.com \
--cc=mkl@pengutronix.de \
--cc=mugunthanvnm@ti.com \
--cc=nsekhar@ti.comnm \
--cc=tglx@linutronix.de \
--cc=tony@atomide.com \
--cc=wg@grandegger.com \
--cc=wsa@the-dreams.de \
/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.