lkml.org 
[lkml]   [2010]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next-2.6 v3] can: Topcliff: PCH_CAN driver: Add Flow control,
On 11/24/2010 01:09 AM, Tomoya MORINAGA wrote:
> On Monday, November 22, 2010 5:27 PM, Marc Kleine-Budde wrote:
>>>>>> Still we have the busy waiting in the TX path. Maybe you can move the
>>>>>> waiting before accessing the if[1] and remove the busy waiting here.
>>>>> I can't understand your saying.
>>>>> For transmitting data, calling pch_can_rw_msg_obj is mandatory.
>>>> Yes, but the busy wait is not needed. It should be enough to do the
>>>> busy-waiting _before_ accessing the if[1].
>>>
>>> Do you mean we should create other pch_can_rw_msg_obj which doesn't have busy wait ?
>> ACK, and this non busy waiting is use in the TX path. But you add a busy
>> wait only function before accessing the if[1] in the TX path.
>
> The "busy waiting" of pch_can_rw_msg_obj is for next processing accesses to Message object.
> If deleting this busy waiting, next processing can access to Message object, regardless previous transfer doesn't
> complete yet.
> Thus, I think, the "busy waiting" is necessary.

Yes, it's necessary, but not where it is done currently.
Let me outline how I think the TX path should look like:

pch_xmit() {
take_care_about_flow_control();
prepare_can_frame_to_be_copied_to_tx_if();

/* most likely we don't have to wait here */
wait_until_tx_if_is_ready();

copy_can_frame_to_tx_if();

/* trigger tx in hardware */
send_tx_if_but_dont_do_busywait();

/* tx_if is busy now, but before we access it, we'll check tx_if is ready */
}

cheers, Marc

--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2010-11-24 13:37    [W:0.073 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site