Blocking wait for interrupt

Johannes Kliemann Johannes.Kliemann at ...250...
Wed Jul 26 10:47:11 CEST 2017


Hi Sebastian,

thanks for your answer.

I tried to implement the relevant parts with Lx::Tasks. It seems to me
that those Tasks are designed to run some kind of endless control flow.
Beside this, I wasn't able to get an interrupt while blocking inside the
task.Yet I'm not sure if I used the tasks correctly.

Maybe I should try to explain how the driver is intended to work.
It consists of two parts, a touch driver that is written natively for
Genode and uses I2C to communicate with its controller. And a I2C driver
for the controller that I try to port from Linux
(drivers/i2c/busses/i2c-designware-core.(c|h)).
The send method of the Linux driver is implemented as I described it in
my first mail.
This behaviour is only triggered if the send method is called and
returns after the message is sent or the controller timed out. The
return causes an unexpected return error in the task.
Beside that the interrupt never occurs while the task is inside the
Linux code.

I'm not sure what I miss or how the Lx::Task should be used exactly in
this case.

Regards,
JK

Am 25.07.2017 um 12:52 schrieb Sebastian Sumpf:
> Hi Johannes,
> 
> On 07/25/2017 08:54 AM, Johannes Kliemann wrote:
>> Hi,
>>
>> I'm currently writing a dde_linux driver that requires to wait for an
>> interrupt to be handled.
>> It basically initializes the hardware and then waits for an event to
>> occur. This event is usually triggered by the interrupt (respectively
>> its handler) which occurs after hardware initialization.
>> My problem is that this interrupt doesn't appear while the function
>> triggering it didn't return. So when this function blocks to wait for
>> the interrupt, a deadlock is created. Besides using the timer I tried to
>> block the execution with a semaphore creating the same problem.
>> Creating an async version is no option due to the architecture of the
>> Linux driver.
>>
>> How are interrupts handled in this case? What causes them to block and
>> how can I work around this?
>>
> 
> If I gather your description correctly, you are executing Linux code
> from the entrypoint context. If this code somehow blocks, lets say by
> calling 'wait_event_interruptible' or something else, the EP cannot
> receive signals, and therefore no interrupts. The solution to this
> problem are 'Lx::Task'(s). All Linux code should be executed by these
> tasks, which are able to block and can be unblocked by the EP upon
> signal reception. A small example can be found under
> 'dde_linux/src/drivers/framebuffer/intel/main.cc', there the Linux code
> is executed by a task in 'run_linux', which is woken up by the
> 'Policy_agent' signal handler.
> 
> Regards,
> 
> Sebastian
> 
> P.S. I hope you are porting a driver and not writing one from scratch ;)
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20170726/28e2237a/attachment.sig>


More information about the users mailing list