Hi Bhupesh,

bhupesh.sharma wrote:
> Hi,
> 
> I don't know if someone is still maintaining the Hynix CCAN driver in
> SocketCAN SVN, but I will appreciate if any one of the developers here, can
> help me out.
> 
> For the past 1 week, I have worked on developing a CCAN driver for my client
> on linux 2.6.27, which takes most of the clues from the Hynix CCAN driver in
> SocketCAN trunk. I have since made changes to align my driver with the new
> `sja1000` like implementation.

There is CCAN support by the old Socket-CAN drivers tree, which does not
use the CAN device drivers interface. Nice to hear that you are trying
to port the CCAN driver.

> Similar to Hynix, my SOC has 2 CAN IPs and I intend to use the same driver
> to handle both the IPs.

Could you be more precise? What SOC are you speaking about?

> 
> Gud news is that when I use CAN-IP1 as a Tx (and send frames using
> `cansend`) and CAN-IP2 as a Rx (and receive frames using `candump`), if I
> transmit only a single CAN Frame, I am successfully able to see proper Rx at
> CAN-IP2.
> 
> Now, the only issue remains that when send multiple CAN frames using the
> `cansend` utility (a older version picked up from
> `http://www.pengutronix.de/software/socket-can/download/canutils/v3.0/`), my
> `candump` complaints that it has received a REMOTE REQUEST, whereas I do
> have not used `-r` option with cansend to send remote frames.
> 
> When I look at Hynix driver in SVN, I see the following check:
> 
> *drivers/can/ccan.c*
> 
> static int ccan_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
>         struct ccan_priv *priv = netdev_priv(dev);
>         struct can_frame *frame = (struct can_frame *)skb->data;
> 
>         spin_lock_irq(&priv->can.irq_lock);
> 
>         ccan_write_object(dev, 0, frame, priv->tx_object);
> #ifdef CCAN_DEBUG
>         priv->bufstat[priv->tx_object]++;
> #endif
>         priv->tx_object++;
>         if (priv->tx_object > 5)
>                 netif_stop_queue(dev);
> 
> ..
> }
> 
> Now, what is the significance of stopping the `netif_queue` when the
> priv->tx_object becomes 5.
> This must be a limitation seen by the developer of this driver in the CCAN
> IP in Hynix.

The netif_stop_queue() tells the network layer to stop sending packets
via the hard_start_xmit() function. It's usually called when no more
hardware objects/buffers are available/free for transmission. See:

http://lxr.linux.no/#linux+v2.6.31/include/linux/netdevice.h#L1305

Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to