Hi Sebastian,
thanks for your explanation, it helped me to understand the problem.
I'm just not yet sure how exactly to call the task.
For the interrupt I have registered it via the Lx::Irq class.
But I'm not sure how to handle the transfer task. Currently I locally
create a Lx::Task that calls
Hi Johannes,
On 07/27/2017 01:42 PM, Johannes Kliemann wrote:
> Hi Sebastian,
>
> yes, that is the function I call from Genode.
>
> And thanks in advance for helping me out.
>
Good. I will try to explain how the Lx::Task approach is supposed to
work in this case:
Your task calls
Hi Sebastian,
yes, that is the function I call from Genode.
And thanks in advance for helping me out.
Regards,
Johannes
Am 27.07.2017 um 10:58 schrieb Sebastian Sumpf:
> Hi Johannes,
>
> I looked into the i2c driver. Are we talking about the 'i2c_dw_xfer'
> function?
>
> Regards,
>
>
Hi Johannes,
I looked into the i2c driver. Are we talking about the 'i2c_dw_xfer'
function?
Regards,
Sebastian
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
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
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
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
