On 31/07/15 11:30, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:22 PM, Sudeep Holla wrote:
Again, sorry for misleading comment, we do need hrtimer as replied on
scpi thread. Any other concern with this patch ?
Polling by hrtimers is OK. Not to mean this is the best solution for
your
On Fri, Jul 31, 2015 at 3:22 PM, Sudeep Holla wrote:
>
>>>
>>> Again, sorry for misleading comment, we do need hrtimer as replied on
>>> scpi thread. Any other concern with this patch ?
>>>
>> Polling by hrtimers is OK. Not to mean this is the best solution for
>> your platform. Please revise the
On 30/07/15 19:11, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 2:18 PM, Sudeep Holla wrote:
[..]
Again, sorry for misleading comment, we do need hrtimer as replied on
scpi thread. Any other concern with this patch ?
Polling by hrtimers is OK. Not to mean this is the best solution for
On 30/07/15 19:11, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 2:18 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
[..]
Again, sorry for misleading comment, we do need hrtimer as replied on
scpi thread. Any other concern with this patch ?
Polling by hrtimers is OK. Not to mean this is the
On Fri, Jul 31, 2015 at 3:22 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
Again, sorry for misleading comment, we do need hrtimer as replied on
scpi thread. Any other concern with this patch ?
Polling by hrtimers is OK. Not to mean this is the best solution for
your platform. Please revise
On 31/07/15 11:30, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:22 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
Again, sorry for misleading comment, we do need hrtimer as replied on
scpi thread. Any other concern with this patch ?
Polling by hrtimers is OK. Not to mean this is the best
On Wed, Jul 29, 2015 at 2:18 PM, Sudeep Holla wrote:
>
>
> On 29/07/15 09:33, Jassi Brar wrote:
>
>> On Mon, Jul 27, 2015 at 3:18 PM, Sudeep Holla
>> wrote:
>>>
>>> On 27/07/15 04:26, Jassi Brar wrote:
>>
>>> we might end-up waiting
>>> for atleast a jiffy even though the
On Wed, Jul 29, 2015 at 2:18 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 29/07/15 09:33, Jassi Brar wrote:
On Mon, Jul 27, 2015 at 3:18 PM, Sudeep Holla sudeep.ho...@arm.com
wrote:
On 27/07/15 04:26, Jassi Brar wrote:
we might end-up waiting
for atleast a jiffy even though the
On 29/07/15 09:33, Jassi Brar wrote:
On Mon, Jul 27, 2015 at 3:18 PM, Sudeep Holla wrote:
On 27/07/15 04:26, Jassi Brar wrote:
we might end-up waiting
for atleast a jiffy even though the response for that message from the
remote is received via interrupt and processed in relatively
On Mon, Jul 27, 2015 at 3:18 PM, Sudeep Holla wrote:
> On 27/07/15 04:26, Jassi Brar wrote:
>>
> we might end-up waiting
> for atleast a jiffy even though the response for that message from the
> remote is received via interrupt and processed in relatively smaller
> time
On Mon, Jul 27, 2015 at 3:18 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 27/07/15 04:26, Jassi Brar wrote:
we might end-up waiting
for atleast a jiffy even though the response for that message from the
remote is received via interrupt and processed in relatively smaller
time
On 29/07/15 09:33, Jassi Brar wrote:
On Mon, Jul 27, 2015 at 3:18 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 27/07/15 04:26, Jassi Brar wrote:
we might end-up waiting
for atleast a jiffy even though the response for that message from the
remote is received via interrupt and
On 27/07/15 04:26, Jassi Brar wrote:
On Fri, Jul 24, 2015 at 2:17 PM, Sudeep Holla wrote:
On 24/07/15 06:02, Jassi Brar wrote:
On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla
wrote:
we might end-up waiting
for atleast a jiffy even though the response for that message from the
remote is
On 27/07/15 04:26, Jassi Brar wrote:
On Fri, Jul 24, 2015 at 2:17 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 24/07/15 06:02, Jassi Brar wrote:
On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla sudeep.ho...@arm.com
wrote:
we might end-up waiting
for atleast a jiffy even though the
On Fri, Jul 24, 2015 at 2:17 PM, Sudeep Holla wrote:
> On 24/07/15 06:02, Jassi Brar wrote:
>>
>> On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla
>> wrote:
>>
>>> we might end-up waiting
>>> for atleast a jiffy even though the response for that message from the
>>> remote is received via interrupt
On Fri, Jul 24, 2015 at 2:17 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 24/07/15 06:02, Jassi Brar wrote:
On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla sudeep.ho...@arm.com
wrote:
we might end-up waiting
for atleast a jiffy even though the response for that message from the
remote is
On 24/07/15 06:02, Jassi Brar wrote:
On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla wrote:
we might end-up waiting
for atleast a jiffy even though the response for that message from the
remote is received via interrupt and processed in relatively smaller
time granularity.
That is wrong.
On 24/07/15 06:02, Jassi Brar wrote:
On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
we might end-up waiting
for atleast a jiffy even though the response for that message from the
remote is received via interrupt and processed in relatively smaller
time granularity.
On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla wrote:
> we might end-up waiting
> for atleast a jiffy even though the response for that message from the
> remote is received via interrupt and processed in relatively smaller
> time granularity.
>
That is wrong.
If the controller supports TX
On Wed, Jul 22, 2015 at 5:58 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
we might end-up waiting
for atleast a jiffy even though the response for that message from the
remote is received via interrupt and processed in relatively smaller
time granularity.
That is wrong.
If the controller
After submitting the message via msg_submit in mbox_send_message, we
wait until it has been transmitted and the remote acknowledges it using
some status register which controller can read(i.e. TXDONE_BY_POLL).
However, since the timer used here to handle that polling for the
transmit completion
After submitting the message via msg_submit in mbox_send_message, we
wait until it has been transmitted and the remote acknowledges it using
some status register which controller can read(i.e. TXDONE_BY_POLL).
However, since the timer used here to handle that polling for the
transmit completion
22 matches
Mail list logo
