From: "Masayuki Ohtake" <masa-korg@dsn•okisemi.com>
To: "Wolfgang Grandegger" <wg@grandegger•com>
Cc: "Wang, Yong Y" <yong.y.wang@intel•com>, <arjan@linux•intel.com>,
<gregkh@suse•de>, "Qi" <qi.wang@intel•com>,
"Andrew Chih Howe" <andrew.chih.howe.khor@intel•com>,
"ML linux-kernel" <linux-kernel@vger•kernel.org>,
"ML netdev" <netdev@vger•kernel.org>,
<socketcan-core@lists•berlios.de>,
"Samuel Ortiz" <sameo@linux•intel.com>,
"Barry Song" <21cnbao@gmail•com>,
"Christian Pellegrin" <chripell@fsfe•org>,
"Wolfram Sang" <w.sang@pengutronix•de>,
"\"David S. Miller\"" <davem@davemloft•net>
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
Date: Wed, 1 Sep 2010 16:45:06 +0900 [thread overview]
Message-ID: <000501cb49a9$9cd4bf00$66f8800a@maildom.okisemi.com> (raw)
In-Reply-To: D5AB6E638E5A3E4B8F4406B113A5A19A28EA29DF@shsmsx501.ccr.corp.intel.com
Sorry, for late response.
----- Original Message -----
From: "Wang, Qi" <qi.wang@intel•com>
To: "Masayuki Ohtak" <masa-korg@dsn•okisemi.com>
Cc: "Khor, Andrew Chih Howe" <andrew.chih.howe.khor@intel•com>; <gregkh@suse•de>; <arjan@linux•intel.com>; "Wang, Yong
Y" <yong.y.wang@intel•com>; "Wolfgang Grandegger" <wg@grandegger•com>
Sent: Thursday, August 12, 2010 6:00 PM
Subject: RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> Hi Ohtak-san,
>
> Would you please answer the question from Wolfgang?
>
> Best Regards,
> Qi.
>
> > -----Original Message-----
> > From: Wolfgang Grandegger [mailto:wg@grandegger•com]
> > Sent: Thursday, August 12, 2010 4:55 PM
> > To: Wang, Qi
> > Cc: Masayuki Ohtak; Khor, Andrew Chih Howe; gregkh@suse•de;
> > arjan@linux•intel.com; Wang, Yong Y
> > Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> >
> > On 08/12/2010 03:29 AM, Wang, Qi wrote:
> > >> -----Original Message-----
> > >> From: Wolfgang Grandegger [mailto:wg@grandegger•com]
> > >> Sent: Wednesday, August 11, 2010 8:31 PM
> > >> To: Masayuki Ohtak
> > >> Cc: meego-dev@meego•com; socketcan-core@lists•berlios.de;
> > >> netdev@vger•kernel.org; Khor, Andrew Chih Howe; gregkh@suse•de;
> > >> arjan@linux•intel.com; Wang, Qi; Wang, Yong Y
> > >> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> > >>
> > >> Hello,
> > >>
> > >> On 08/11/2010 02:25 AM, Masayuki Ohtak wrote:
> > >>> CAN driver of Topcliff PCH
> > >>>
> > >>> Topcliff PCH is the platform controller hub that is going to be used in
> > >>> Intel's upcoming general embedded platform. All IO peripherals in
> > >>> Topcliff PCH are actually devices sitting on AMBA bus.
> > >>
> > >> That's interesting. Where can I/we find more information about this CAN
> > >> controller, e.g. data-sheets. It seems to have a few interesting
> > >> features (message scheduler, etc.).
> > >
> > > I remove all the maillist, and show you something about this platform.
> >
> > Like Greg, I also prefer the public discussion.
> >
> > >
> > > Topcliff PCH is connected with Tunnelcreak (A kind of ATOM-based processor,
> > which integrate Memory controller, GFX and RC). And Topcliff is a kind of
> > stand-alone ARM-based processor, so it has AMBA-based peripherals, such as
> > CAN, GBE, I2C.
> > >
> > > Topcliff connected with Tunnelcreak via PCIe x1 lane. And PCH_PHUB works
> > as a gateway, which transform PCIe transaction to AMBA transaction, and vice
> > versa.
> > >
> > > The datasheet of those two chips aren't open now.
> >
> > Thanks for the info.
> >
> > >>> Topcliff PCH has CAN I/F. This driver enables CAN function.
> > >>>
> > >>> Signed-off-by: Masayuki Ohtake <masa-korg@dsn•okisemi.com>
> > >>
> > >> Thanks for your contribution. Unfortunately, there are many issues,
> > >> especially the driver is not yet conform with the Socket-CAN driver API:
> > >>
> > >> - My first observation was:
> > >>
> > >> $ wc -l pch_can.c
> > >> 4076 pch_can.c
> > >> $ grep dev_dbg pch_can.c | wc -l
> > >> 143
> > >>
> > >> That's a lot of code, mainly debugging code, I think. This needs to
> > >> be cleaned up sooner than later. dev_dbg's should be restricted to a
> > >> few useful for the real users.
We will reduce dev_dbg code.
> > >>
> > >> - The values for the hw-specific bit-timing registers should be derived
> > >> from the calculated values in "priv->can.bittiming":
> > >>
> > >> http://lxr.linux.no/#linux+v2.6.35/include/linux/can/netlink.h#L17
> > >>
I show current pch_can code below.
+static int pch_set_bittiming(struct net_device *ndev)
+{
+ struct pch_can_priv *priv = netdev_priv(ndev);
+ struct pch_can_os *dev_can_os = priv->pch_can_os_p;
+ const struct can_bittiming *bt = &priv->can.bittiming;
Is the above TRUE, isn't it ?
> > >> - The driver should handle state changes and communicate them to the
> > >> user space via error messages, if possible.
> > >>
What's "state chage" mean ?
> > >> - The driver should report errors to the user space via error messages.
> > >>
Is the above mean using alloc_can_err_skb and set error info and notify to kernel with netif_rx ?
> > >> - Bus errors seem not to be handled properly.I'm missing can_bus_off().
> > >> Does the controller recover from bus-off automatically?
No.
CAN driver recovers from Bus-off state.
> > >>
> > >> - I see that the driver uses many TX and RX objects. How do you avoid
> > >> out-of-order transmission and reception?
> > > What do you mean out-of-order RX and TX?
> > > Atom processor only supports in-order execution, and PCIe-based peripherals
> > can solve it with consumer-producer model. Actually IC designer will take care
> > of out-of-order PCIe CPLD transaction.
> >
> > I mean out-of-order transmission to or from the CAN bus. This is handled
> > by the CAN controller hardware. It has nothing to to with the processor.
Cannot avoid occurring rx or tx our-of-order.
Thanks, Ohtake(OKISemi)
next prev parent reply other threads:[~2010-09-01 7:45 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-11 0:25 [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35 Masayuki Ohtak
[not found] ` <4C61EDE5.4030505-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
2010-08-11 10:37 ` Daniel Baluta
2010-08-12 1:42 ` Wang, Qi
2010-08-12 2:04 ` Greg KH
2010-08-12 2:13 ` Wang, Qi
[not found] ` <20100812020414.GD14121-l3A5Bk7waGM@public.gmane.org>
2010-08-12 6:25 ` Oliver Hartkopp
2010-08-12 6:29 ` Wang, Qi
2010-08-12 2:39 ` Masayuki Ohtake
[not found] ` <D5AB6E638E5A3E4B8F4406B113A5A19A28EA26EB-QQHDSDV1ERZpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2010-08-12 5:17 ` Daniel Baluta
2010-08-12 9:03 ` Wolfgang Grandegger
2010-08-13 0:23 ` Wang, Qi
[not found] ` <D5AB6E638E5A3E4B8F4406B113A5A19A28EA2AB1-QQHDSDV1ERZpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2010-08-13 6:11 ` Daniel Baluta
2010-08-13 10:58 ` Wolfgang Grandegger
2010-08-20 6:01 ` Masayuki Ohtake
[not found] ` <000f01cb402d$34b675b0$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
2010-08-20 7:59 ` Wolfgang Grandegger
2010-08-20 8:37 ` Masayuki Ohtake
2010-08-11 12:31 ` Wolfgang Grandegger
[not found] ` <D5AB6E638E5A3E4B8F4406B113A5A19A28EA26CC@shsmsx501.ccr.corp.intel.com>
[not found] ` <4C63B6C9.5050804@grandegger.com>
[not found] ` <D5AB6E638E5A3E4B8F4406B113A5A19A28EA29DF@shsmsx501.ccr.corp.intel.com>
2010-09-01 7:45 ` Masayuki Ohtake [this message]
[not found] ` <000501cb49a9$9cd4bf00$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
2010-09-01 17:04 ` out-of-order tx objects - was " Oliver Hartkopp
2010-09-01 18:51 ` Wolfgang Grandegger
2010-09-02 3:19 ` Masayuki Ohtake
[not found] ` <001301cb4a4d$b4c4ba80$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
2010-09-02 6:32 ` Wolfgang Grandegger
2010-08-11 13:04 ` Marc Kleine-Budde
2010-09-13 12:07 ` Masayuki Ohtake
[not found] ` <005f01cb533e$5c21d530$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
2010-09-13 12:29 ` Marc Kleine-Budde
2010-09-14 0:46 ` Masayuki Ohtake
2010-09-14 7:08 ` Marc Kleine-Budde
[not found] ` <003a01cb53a6$4ca724d0$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
2010-09-15 7:42 ` Wolfgang Grandegger
[not found] ` <4C9078D3.50300-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
2010-09-15 9:42 ` Oliver Hartkopp
2010-09-15 10:55 ` Wolfgang Grandegger
2010-09-15 12:04 ` Marc Kleine-Budde
2010-09-15 12:11 ` Wolfgang Grandegger
2010-09-13 15:22 ` Greg KH
2010-09-14 8:48 ` Masayuki Ohtake
[not found] ` <00ca01cb53e9$a50c1930$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
2010-09-14 13:10 ` Greg KH
2010-09-15 1:21 ` Masayuki Ohtake
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='000501cb49a9$9cd4bf00$66f8800a@maildom.okisemi.com' \
--to=masa-korg@dsn$(echo .)okisemi.com \
--cc=21cnbao@gmail$(echo .)com \
--cc=andrew.chih.howe.khor@intel$(echo .)com \
--cc=arjan@linux$(echo .)intel.com \
--cc=chripell@fsfe$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=gregkh@suse$(echo .)de \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=qi.wang@intel$(echo .)com \
--cc=sameo@linux$(echo .)intel.com \
--cc=socketcan-core@lists$(echo .)berlios.de \
--cc=w.sang@pengutronix$(echo .)de \
--cc=wg@grandegger$(echo .)com \
--cc=yong.y.wang@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox