* [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled
@ 2012-02-21 16:00 Alexander Stein
2012-02-21 16:00 ` [PATCH 2/2] pch_can: (re)start Tx queue at first entry Alexander Stein
2012-02-21 16:25 ` [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled Wolfgang Grandegger
0 siblings, 2 replies; 7+ messages in thread
From: Alexander Stein @ 2012-02-21 16:00 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde; +Cc: linux-can, Alexander Stein
If all Tx buffers are empty and we start queuing frames (more than Tx
buffer size) beginning at the last message buffer we will override the
first inserted entry if it doesn't get sent meanwhile, e.g. low priority
or ACK error. There is no stop condition when all buffers are used.
We will get get awoken by pch_can_tx_complete when the last entry is sent.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
drivers/net/can/pch_can.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 6edc25e..3af5341 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -903,9 +903,7 @@ static netdev_tx_t pch_xmit(struct sk_buff *skb, struct net_device *ndev)
tx_obj_no = priv->tx_obj;
if (priv->tx_obj == PCH_TX_OBJ_END) {
- if (ioread32(&priv->regs->treq2) & PCH_TREQ2_TX_MASK)
- netif_stop_queue(ndev);
-
+ netif_stop_queue(ndev);
priv->tx_obj = PCH_TX_OBJ_START;
} else {
priv->tx_obj++;
--
1.7.3.4
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/2] pch_can: (re)start Tx queue at first entry
2012-02-21 16:00 [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled Alexander Stein
@ 2012-02-21 16:00 ` Alexander Stein
2012-02-21 16:25 ` [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled Wolfgang Grandegger
1 sibling, 0 replies; 7+ messages in thread
From: Alexander Stein @ 2012-02-21 16:00 UTC (permalink / raw)
To: Wolfgang Grandegger, Marc Kleine-Budde; +Cc: linux-can, Alexander Stein
If we restart and our queue stopped at the last entry we will already
stop it again after the first message inserted.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
---
drivers/net/can/pch_can.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 3af5341..8d617c7 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -817,6 +817,9 @@ static void pch_can_start(struct net_device *ndev)
pch_can_set_tx_all(priv, 1);
pch_can_set_rx_all(priv, 1);
+ /* Reset Tx Obj to 1st one */
+ priv->tx_obj = PCH_TX_OBJ_START;
+
/* Setting the CAN to run mode. */
pch_can_set_run_mode(priv, PCH_CAN_RUN);
--
1.7.3.4
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled
2012-02-21 16:00 [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled Alexander Stein
2012-02-21 16:00 ` [PATCH 2/2] pch_can: (re)start Tx queue at first entry Alexander Stein
@ 2012-02-21 16:25 ` Wolfgang Grandegger
2012-02-21 16:30 ` Alexander Stein
1 sibling, 1 reply; 7+ messages in thread
From: Wolfgang Grandegger @ 2012-02-21 16:25 UTC (permalink / raw)
To: Alexander Stein; +Cc: Marc Kleine-Budde, linux-can
Hi Alexander,
On 02/21/2012 05:00 PM, Alexander Stein wrote:
> If all Tx buffers are empty and we start queuing frames (more than Tx
> buffer size) beginning at the last message buffer we will override the
> first inserted entry if it doesn't get sent meanwhile, e.g. low priority
> or ACK error. There is no stop condition when all buffers are used.
> We will get get awoken by pch_can_tx_complete when the last entry is sent.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> drivers/net/can/pch_can.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
> index 6edc25e..3af5341 100644
> --- a/drivers/net/can/pch_can.c
> +++ b/drivers/net/can/pch_can.c
> @@ -903,9 +903,7 @@ static netdev_tx_t pch_xmit(struct sk_buff *skb, struct net_device *ndev)
>
> tx_obj_no = priv->tx_obj;
> if (priv->tx_obj == PCH_TX_OBJ_END) {
> - if (ioread32(&priv->regs->treq2) & PCH_TREQ2_TX_MASK)
> - netif_stop_queue(ndev);
> -
> + netif_stop_queue(ndev);
> priv->tx_obj = PCH_TX_OBJ_START;
> } else {
> priv->tx_obj++;
The pch_can uses a C_CAN core (and for maintenance reasons we would like
to get ride of it sooner than later). In that driver the queue is
stopped here:
http://lxr.linux.no/#linux+v3.2.7/drivers/net/can/c_can/c_can.c#L508
Therefore I'm not sure if your fix is enough (without looking into the
manual). I could send you a "pch_pci" driver patch for C_CAN, which
would allow you to use it. What kernel version are you using?
Thanks,
Wolfgang.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled
2012-02-21 16:25 ` [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled Wolfgang Grandegger
@ 2012-02-21 16:30 ` Alexander Stein
2012-02-22 10:58 ` Wolfgang Grandegger
0 siblings, 1 reply; 7+ messages in thread
From: Alexander Stein @ 2012-02-21 16:30 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Marc Kleine-Budde, linux-can
Hello Wolfgang,
Am Dienstag, 21. Februar 2012, 17:25:57 schrieb Wolfgang Grandegger:
> Hi Alexander,
>
> On 02/21/2012 05:00 PM, Alexander Stein wrote:
> > If all Tx buffers are empty and we start queuing frames (more than Tx
> > buffer size) beginning at the last message buffer we will override the
> > first inserted entry if it doesn't get sent meanwhile, e.g. low priority
> > or ACK error. There is no stop condition when all buffers are used.
> > We will get get awoken by pch_can_tx_complete when the last entry is sent.
> >
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > ---
> > drivers/net/can/pch_can.c | 4 +---
> > 1 files changed, 1 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
> > index 6edc25e..3af5341 100644
> > --- a/drivers/net/can/pch_can.c
> > +++ b/drivers/net/can/pch_can.c
> > @@ -903,9 +903,7 @@ static netdev_tx_t pch_xmit(struct sk_buff *skb, struct net_device *ndev)
> >
> > tx_obj_no = priv->tx_obj;
> > if (priv->tx_obj == PCH_TX_OBJ_END) {
> > - if (ioread32(&priv->regs->treq2) & PCH_TREQ2_TX_MASK)
> > - netif_stop_queue(ndev);
> > -
> > + netif_stop_queue(ndev);
> > priv->tx_obj = PCH_TX_OBJ_START;
> > } else {
> > priv->tx_obj++;
>
> The pch_can uses a C_CAN core (and for maintenance reasons we would like
> to get ride of it sooner than later). In that driver the queue is
> stopped here:
>
> http://lxr.linux.no/#linux+v3.2.7/drivers/net/can/c_can/c_can.c#L508
Does the C_CAN core have a real fifo? The message "fifo" in PCH CAN just uses the first message object. So you will reorder message under some conditions if used like a real fifo.
> Therefore I'm not sure if your fix is enough (without looking into the
> manual). I could send you a "pch_pci" driver patch for C_CAN, which
> would allow you to use it. What kernel version are you using?
We are currently using 2.6.39.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
August-Bebel-Str. 29
D-07973 Greiz
Tel: +49-3661-6279-0, Fax: +49-3661-6279-99
eMail: Alexander.Stein@systec-electronic.com
Internet: http://www.systec-electronic.com
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Jena, HRB 205563
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled
2012-02-21 16:30 ` Alexander Stein
@ 2012-02-22 10:58 ` Wolfgang Grandegger
2012-02-22 11:11 ` Bhupesh SHARMA
0 siblings, 1 reply; 7+ messages in thread
From: Wolfgang Grandegger @ 2012-02-22 10:58 UTC (permalink / raw)
To: Alexander Stein; +Cc: Marc Kleine-Budde, linux-can
On 02/21/2012 05:30 PM, Alexander Stein wrote:
> Hello Wolfgang,
>
> Am Dienstag, 21. Februar 2012, 17:25:57 schrieb Wolfgang Grandegger:
>> Hi Alexander,
>>
>> On 02/21/2012 05:00 PM, Alexander Stein wrote:
>>> If all Tx buffers are empty and we start queuing frames (more than Tx
>>> buffer size) beginning at the last message buffer we will override the
>>> first inserted entry if it doesn't get sent meanwhile, e.g. low priority
>>> or ACK error. There is no stop condition when all buffers are used.
>>> We will get get awoken by pch_can_tx_complete when the last entry is sent.
>>>
>>> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
>>> ---
>>> drivers/net/can/pch_can.c | 4 +---
>>> 1 files changed, 1 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
>>> index 6edc25e..3af5341 100644
>>> --- a/drivers/net/can/pch_can.c
>>> +++ b/drivers/net/can/pch_can.c
>>> @@ -903,9 +903,7 @@ static netdev_tx_t pch_xmit(struct sk_buff *skb, struct net_device *ndev)
>>>
>>> tx_obj_no = priv->tx_obj;
>>> if (priv->tx_obj == PCH_TX_OBJ_END) {
>>> - if (ioread32(&priv->regs->treq2) & PCH_TREQ2_TX_MASK)
>>> - netif_stop_queue(ndev);
>>> -
>>> + netif_stop_queue(ndev);
>>> priv->tx_obj = PCH_TX_OBJ_START;
>>> } else {
>>> priv->tx_obj++;
>>
>> The pch_can uses a C_CAN core (and for maintenance reasons we would like
>> to get ride of it sooner than later). In that driver the queue is
>> stopped here:
>>
>> http://lxr.linux.no/#linux+v3.2.7/drivers/net/can/c_can/c_can.c#L508
>
> Does the C_CAN core have a real fifo? The message "fifo" in PCH CAN just uses the first message object. So you will reorder message under some conditions if used like a real fifo.
My understanding is that the CAN controller cores are identical. What
the driver actually uses might be different. Out of order transmission
of message are *not* allowed and the software must take care. With a
real fifo that might be tricky, indeed.
>> Therefore I'm not sure if your fix is enough (without looking into the
>> manual). I could send you a "pch_pci" driver patch for C_CAN, which
>> would allow you to use it. What kernel version are you using?
>
> We are currently using 2.6.39.
OK, I'm going to prepare a patch for that kernel version first.
More soon...
Wolfgang.
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled
2012-02-22 10:58 ` Wolfgang Grandegger
@ 2012-02-22 11:11 ` Bhupesh SHARMA
2012-02-22 13:05 ` Wolfgang Grandegger
0 siblings, 1 reply; 7+ messages in thread
From: Bhupesh SHARMA @ 2012-02-22 11:11 UTC (permalink / raw)
To: Wolfgang Grandegger, Alexander Stein
Cc: Marc Kleine-Budde, linux-can@vger.kernel.org
> -----Original Message-----
> From: linux-can-owner@vger.kernel.org [mailto:linux-can-
> owner@vger.kernel.org] On Behalf Of Wolfgang Grandegger
> Sent: Wednesday, February 22, 2012 4:29 PM
> To: Alexander Stein
> Cc: Marc Kleine-Budde; linux-can@vger.kernel.org
> Subject: Re: [PATCH 1/2] pch_can: Stop netif queue if last message
> buffer is filled
>
> On 02/21/2012 05:30 PM, Alexander Stein wrote:
> > Hello Wolfgang,
> >
> > Am Dienstag, 21. Februar 2012, 17:25:57 schrieb Wolfgang Grandegger:
> >> Hi Alexander,
> >>
> >> On 02/21/2012 05:00 PM, Alexander Stein wrote:
> >>> If all Tx buffers are empty and we start queuing frames (more than
> Tx
> >>> buffer size) beginning at the last message buffer we will override
> the
> >>> first inserted entry if it doesn't get sent meanwhile, e.g. low
> priority
> >>> or ACK error. There is no stop condition when all buffers are used.
> >>> We will get get awoken by pch_can_tx_complete when the last entry
> is sent.
> >>>
> >>> Signed-off-by: Alexander Stein <alexander.stein@systec-
> electronic.com>
> >>> ---
> >>> drivers/net/can/pch_can.c | 4 +---
> >>> 1 files changed, 1 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
> >>> index 6edc25e..3af5341 100644
> >>> --- a/drivers/net/can/pch_can.c
> >>> +++ b/drivers/net/can/pch_can.c
> >>> @@ -903,9 +903,7 @@ static netdev_tx_t pch_xmit(struct sk_buff
> *skb, struct net_device *ndev)
> >>>
> >>> tx_obj_no = priv->tx_obj;
> >>> if (priv->tx_obj == PCH_TX_OBJ_END) {
> >>> - if (ioread32(&priv->regs->treq2) & PCH_TREQ2_TX_MASK)
> >>> - netif_stop_queue(ndev);
> >>> -
> >>> + netif_stop_queue(ndev);
> >>> priv->tx_obj = PCH_TX_OBJ_START;
> >>> } else {
> >>> priv->tx_obj++;
> >>
> >> The pch_can uses a C_CAN core (and for maintenance reasons we would
> like
> >> to get ride of it sooner than later). In that driver the queue is
> >> stopped here:
> >>
> >> http://lxr.linux.no/#linux+v3.2.7/drivers/net/can/c_can/c_can.c#L508
> >
> > Does the C_CAN core have a real fifo? The message "fifo" in PCH CAN
> just uses the first message object. So you will reorder message under
> some conditions if used like a real fifo.
>
> My understanding is that the CAN controller cores are identical. What
> the driver actually uses might be different. Out of order transmission
> of message are *not* allowed and the software must take care. With a
> real fifo that might be tricky, indeed.
The C_CAN core has no real FIFO. The same needs to be implemented via SW.
This is necessary because the message objects are filled/emptied as per the
message object priority. As soon as you mark the Message Object 0 as "free"
incoming messages will be stored here (if you are using Msg 0 for Rx purposes),
otherwise this message object will be Tx'ed first (if you are using Msg 0 for
Tx purposes).
Note: The C_CAN UM talks about a possibility of configuring a FIFO for Rx objects
but you need SW mechanisms to again maintain "in-order" reception.
> >> Therefore I'm not sure if your fix is enough (without looking into
> the
> >> manual). I could send you a "pch_pci" driver patch for C_CAN, which
> >> would allow you to use it. What kernel version are you using?
> >
> > We are currently using 2.6.39.
>
> OK, I'm going to prepare a patch for that kernel version first.
>
> More soon...
>
I have made a series of changes in my C_CAN driver which I need to merge
and submit to mainline.
Will do that in coming days. It is on my TO-DO list for long now :(
Regards,
Bhupesh
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled
2012-02-22 11:11 ` Bhupesh SHARMA
@ 2012-02-22 13:05 ` Wolfgang Grandegger
0 siblings, 0 replies; 7+ messages in thread
From: Wolfgang Grandegger @ 2012-02-22 13:05 UTC (permalink / raw)
To: Bhupesh SHARMA
Cc: Alexander Stein, Marc Kleine-Budde, linux-can@vger.kernel.org
Hi Bhupesh,
On 02/22/2012 12:11 PM, Bhupesh SHARMA wrote:
>> -----Original Message-----
>> From: linux-can-owner@vger.kernel.org [mailto:linux-can-
>> owner@vger.kernel.org] On Behalf Of Wolfgang Grandegger
>> Sent: Wednesday, February 22, 2012 4:29 PM
>> To: Alexander Stein
>> Cc: Marc Kleine-Budde; linux-can@vger.kernel.org
>> Subject: Re: [PATCH 1/2] pch_can: Stop netif queue if last message
>> buffer is filled
>>
>> On 02/21/2012 05:30 PM, Alexander Stein wrote:
>>> Hello Wolfgang,
>>>
>>> Am Dienstag, 21. Februar 2012, 17:25:57 schrieb Wolfgang Grandegger:
>>>> Hi Alexander,
>>>>
>>>> On 02/21/2012 05:00 PM, Alexander Stein wrote:
>>>>> If all Tx buffers are empty and we start queuing frames (more than
>> Tx
>>>>> buffer size) beginning at the last message buffer we will override
>> the
>>>>> first inserted entry if it doesn't get sent meanwhile, e.g. low
>> priority
>>>>> or ACK error. There is no stop condition when all buffers are used.
>>>>> We will get get awoken by pch_can_tx_complete when the last entry
>> is sent.
>>>>>
>>>>> Signed-off-by: Alexander Stein <alexander.stein@systec-
>> electronic.com>
>>>>> ---
>>>>> drivers/net/can/pch_can.c | 4 +---
>>>>> 1 files changed, 1 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
>>>>> index 6edc25e..3af5341 100644
>>>>> --- a/drivers/net/can/pch_can.c
>>>>> +++ b/drivers/net/can/pch_can.c
>>>>> @@ -903,9 +903,7 @@ static netdev_tx_t pch_xmit(struct sk_buff
>> *skb, struct net_device *ndev)
>>>>>
>>>>> tx_obj_no = priv->tx_obj;
>>>>> if (priv->tx_obj == PCH_TX_OBJ_END) {
>>>>> - if (ioread32(&priv->regs->treq2) & PCH_TREQ2_TX_MASK)
>>>>> - netif_stop_queue(ndev);
>>>>> -
>>>>> + netif_stop_queue(ndev);
>>>>> priv->tx_obj = PCH_TX_OBJ_START;
>>>>> } else {
>>>>> priv->tx_obj++;
>>>>
>>>> The pch_can uses a C_CAN core (and for maintenance reasons we would
>> like
>>>> to get ride of it sooner than later). In that driver the queue is
>>>> stopped here:
>>>>
>>>> http://lxr.linux.no/#linux+v3.2.7/drivers/net/can/c_can/c_can.c#L508
>>>
>>> Does the C_CAN core have a real fifo? The message "fifo" in PCH CAN
>> just uses the first message object. So you will reorder message under
>> some conditions if used like a real fifo.
>>
>> My understanding is that the CAN controller cores are identical. What
>> the driver actually uses might be different. Out of order transmission
>> of message are *not* allowed and the software must take care. With a
>> real fifo that might be tricky, indeed.
>
> The C_CAN core has no real FIFO. The same needs to be implemented via SW.
> This is necessary because the message objects are filled/emptied as per the
> message object priority. As soon as you mark the Message Object 0 as "free"
> incoming messages will be stored here (if you are using Msg 0 for Rx purposes),
> otherwise this message object will be Tx'ed first (if you are using Msg 0 for
> Tx purposes).
>
> Note: The C_CAN UM talks about a possibility of configuring a FIFO for Rx objects
> but you need SW mechanisms to again maintain "in-order" reception.
Thanks for clarification.
>>>> Therefore I'm not sure if your fix is enough (without looking into
>> the
>>>> manual). I could send you a "pch_pci" driver patch for C_CAN, which
>>>> would allow you to use it. What kernel version are you using?
>>>
>>> We are currently using 2.6.39.
>>
>> OK, I'm going to prepare a patch for that kernel version first.
>>
>> More soon...
>>
>
> I have made a series of changes in my C_CAN driver which I need to merge
> and submit to mainline.
>
> Will do that in coming days. It is on my TO-DO list for long now :(
Well, that's almost normal.
Wolfgang.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-02-22 13:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-21 16:00 [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled Alexander Stein
2012-02-21 16:00 ` [PATCH 2/2] pch_can: (re)start Tx queue at first entry Alexander Stein
2012-02-21 16:25 ` [PATCH 1/2] pch_can: Stop netif queue if last message buffer is filled Wolfgang Grandegger
2012-02-21 16:30 ` Alexander Stein
2012-02-22 10:58 ` Wolfgang Grandegger
2012-02-22 11:11 ` Bhupesh SHARMA
2012-02-22 13:05 ` Wolfgang Grandegger
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.