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. Similar to Hynix, my SOC has 2 CAN IPs and I intend to use the same driver to handle both the IPs. 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. This may help me in understanding the issue I am having with my CCAN. Thanks, Bhupesh -- View this message in context: http://www.nabble.com/Query-regarding-C_CAN-driver-for-Hynix-tp26030520p26030520.html Sent from the Socket-CAN Core mailing list archive at Nabble.com. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
