Hi David,
See inline
David Wooff wrote:
Hi David,
I have replied direct as well since the list sometimes bounces me.
I tend to solve this problem using a kernel worker thread and one
or more message queues.
The interrupt and the user task can all send requests to the
message queue which wakes up the thread to process each request
in turn.
In this way you can be sure that you have complete control over
the device without being concerned over interrupts etc.
The only drawback is possible increased latency for interrupt
processing.
You can have one queue for interrupts and one for user tasks and
give priority to servicing the interrupt requests first.
You will still have to complete the user service request before
you get to the interrupt.
So provided that you can stand the possible delay in servicing the
interrupt "bottom half" the thread solution may work for you.
Good luck. Please ask if you have more questions
Regards
Phil Wilshire
Hi Phil,
thanks for your very quick and helpful reply!
I hadn't considered using more than one queue, but does this guarantee
exclusive access to the hardware? i.e. if I queue the same work
function (which does the register accesses) on 2 different queues,
would each invocation of that function be exclusive or are they just
executed in separate threads (or have I got it completely wrong?).
You have one thread that gets woken up when either queue is empty
The thread will service any interrupt requests first and any user
request second.
There are two queues to allow interrupts to have their own queue so you
dont have to look for the interrupt messages on the user queue.
So to recap.
One thread = exclusive hardware access.
Two queues - wake up when either is not empty.
Interrupt Queue is serviced first.
I could write the code for you but I'd have to charge a small fee.
regards
Phil
Am I right to equate each distinct workqueue to an equally distinct
thread?
Many thanks again,
Dave W.
This electronic transmission is strictly confidential and intended
solely for the addressee(s). If you are not the intended addressee,
you must not disclose, copy or take any action in reliance of this
email. If you have received this email in error please notify the
sender as soon as possible. Any views expressed within this email may
not necessarily be the views held by Calrec Audio Ltd. Calrec Audio
Ltd have taken measures to ensure this email is free from computer
viruses, however it is recommended that you also employ anti-virus
measures on your computer systems.
Calrec Audio Ltd. Registered in England. Registration
number: 02392336. WEEE registration number: WEE/JE0051TQ/PRO.
Registered address: Nutclough Mill, Hebden Bridge, West Yorks, HX7 8EZ.
------------------------------------------------------------------------
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
