[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C7EA0CC.2030609@grandegger.com>
Date: Wed, 01 Sep 2010 20:51:56 +0200
From: Wolfgang Grandegger <wg@...ndegger.com>
To: Masayuki Ohtake <masa-korg@....okisemi.com>
CC: Andrew Chih Howe <andrew.chih.howe.khor@...el.com>,
Qi <qi.wang@...el.com>, ML netdev <netdev@...r.kernel.org>,
gregkh@...e.de, ML linux-kernel <linux-kernel@...r.kernel.org>,
"Wang, Yong Y" <yong.y.wang@...el.com>,
socketcan-core@...ts.berlios.de, arjan@...ux.intel.com,
"David S. Miller" <davem@...emloft.net>,
Christian Pellegrin <chripell@...e.org>,
Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
Hello,
On 09/01/2010 09:45 AM, Masayuki Ohtake wrote:
> Sorry, for late response.
> ----- Original Message -----
> From: "Wang, Qi" <qi.wang@...el.com>
> To: "Masayuki Ohtak" <masa-korg@....okisemi.com>
> Cc: "Khor, Andrew Chih Howe" <andrew.chih.howe.khor@...el.com>; <gregkh@...e.de>; <arjan@...ux.intel.com>; "Wang, Yong
> Y" <yong.y.wang@...el.com>; "Wolfgang Grandegger" <wg@...ndegger.com>
> Sent: Thursday, August 12, 2010 6:00 PM
> Subject: RE: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
...
>>>>> - 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 code fragment looks good. In that function you should then *derive*
the values of the bit-timing registers from the data fields of "bt". For
the SJA1000, you find the code here:
http://lxr.linux.no/#linux+v2.6.35/drivers/net/can/sja1000/sja1000.c#L202
>>>>> - The driver should handle state changes and communicate them to the
>>>>> user space via error messages, if possible.
>>>>>
> What's "state chage" mean ?
Googling for "can bis states" returned:
http://www.softing.com/home/en/industrial-automation/products/can-bus/more-can-bus/error-handling/error-states.php?navanchor=3010510
The CAN controller usually triggers an interrupt when the state changes,
which allows the driver to track the CAN state and deliver that
information to the user space.
>>>>> - 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 ?
Yes. Please search "Documentation/networking/can.txt" for "error frames"
for further information.
>>>>> - 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.
You mean: "It does *not" recover automatically"! Right?
>
>>>>>
>>>>> - 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.
It is a *requirement* as Oliver already pointed out. It's easy to
achieve if just one TX object is used but it might be tricky with more
than one.
Wolfgang.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists